NetBeans - the UI for Maven

classic Classic list List threaded Threaded
21 messages Options
12
Reply | Threaded
Open this post in threaded view
|

NetBeans - the UI for Maven

Jaroslav Tulach
Hi guys,
the Apache NetBeans release 10 is (almost) finished and ready for download.
Time to look forward: Long live Apache NetBeans - the UI for Apache Maven!

NetBeans is known for its excellent Maven support. Time to bring it to new
level - time to lead all NetBeans newbies directly into Maven hands:

Whenever one creates new Java project from scratch a Maven project should be
created.

Currently the default project type is Ant based, but as Jesse Glick (the
author of the Ant based projects integration) once asked: "Is anybody still
using that!?" That is the question! Newcomers use it, but otherwise it is
useless dead end road. Starting new Ant based project in a year 2018 is a
nonsence!

The current duality of Ant/Maven project support also wastes precious NetBeans
development resources - features are usually implemented for Ant based
projects first and only then ported to Maven. That's misfocused and upside
down.

Let's make the switch and offer Maven projects by default. Maven is well
suited for the task: it is standard, well adopted build system. Maven comes
with project archetypes that will serve as great starting templates for our
newly generated project.

What will change? Not the code, but the presentation: When one invokes "New
Project" in NetBeans 11, there should be:

Java:
  - Java Application
  - Java Frontend Application
  - Project from Archetype
  - POM Project
  - NetBeans Application

Ant(ic)/Java:
  - Java Free-Form Project
  - Java Modular Project
  - Java Project with Existing Sources
  - Java Class Library
  - Java Application

Ant(ic)/JavaFX:
  - JavaFX Application
  - JavaFX Preloader
  - JavaFX FXML Application
  - JavaFX in Swing Application
  - JavaFX Project with Existing Sources

Ant(ic)/NetBeans Modules:
  - Module
  - Module Suite
  - Library Wrapper Module
  - NetBeans Platform Application

PHP:
  // unchanged

HTML5/JavaScript:
  // unchanged


The "Java" category will offer only Maven based projects. I hope this change
will be welcomed by NetBeans as well as Maven supporters and will help Apache
NetBeans to move forward and focus on support of technology that matters!

Best regards and thanks in advance for your support.
Jaroslav Tulach
NetBeans founder & initial architect




---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: NetBeans - the UI for Maven

Vano Beridze
Great idea.

On Sat, Nov 24, 2018, 11:53 AM Jaroslav Tulach <[hidden email]
wrote:

> Hi guys,
> the Apache NetBeans release 10 is (almost) finished and ready for
> download.
> Time to look forward: Long live Apache NetBeans - the UI for Apache Maven!
>
> NetBeans is known for its excellent Maven support. Time to bring it to new
> level - time to lead all NetBeans newbies directly into Maven hands:
>
> Whenever one creates new Java project from scratch a Maven project should
> be
> created.
>
> Currently the default project type is Ant based, but as Jesse Glick (the
> author of the Ant based projects integration) once asked: "Is anybody
> still
> using that!?" That is the question! Newcomers use it, but otherwise it is
> useless dead end road. Starting new Ant based project in a year 2018 is a
> nonsence!
>
> The current duality of Ant/Maven project support also wastes precious
> NetBeans
> development resources - features are usually implemented for Ant based
> projects first and only then ported to Maven. That's misfocused and upside
> down.
>
> Let's make the switch and offer Maven projects by default. Maven is well
> suited for the task: it is standard, well adopted build system. Maven
> comes
> with project archetypes that will serve as great starting templates for
> our
> newly generated project.
>
> What will change? Not the code, but the presentation: When one invokes
> "New
> Project" in NetBeans 11, there should be:
>
> Java:
>   - Java Application
>   - Java Frontend Application
>   - Project from Archetype
>   - POM Project
>   - NetBeans Application
>
> Ant(ic)/Java:
>   - Java Free-Form Project
>   - Java Modular Project
>   - Java Project with Existing Sources
>   - Java Class Library
>   - Java Application
>
> Ant(ic)/JavaFX:
>   - JavaFX Application
>   - JavaFX Preloader
>   - JavaFX FXML Application
>   - JavaFX in Swing Application
>   - JavaFX Project with Existing Sources
>
> Ant(ic)/NetBeans Modules:
>   - Module
>   - Module Suite
>   - Library Wrapper Module
>   - NetBeans Platform Application
>
> PHP:
>   // unchanged
>
> HTML5/JavaScript:
>   // unchanged
>
>
> The "Java" category will offer only Maven based projects. I hope this
> change
> will be welcomed by NetBeans as well as Maven supporters and will help
> Apache
> NetBeans to move forward and focus on support of technology that matters!
>
> Best regards and thanks in advance for your support.
> Jaroslav Tulach
> NetBeans founder & initial architect
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
> For further information about the NetBeans mailing lists, visit:
> https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
>
>
>
>
Reply | Threaded
Open this post in threaded view
|

Re: NetBeans - the UI for Maven

Jean-Marc Borer
In reply to this post by Jaroslav Tulach
Hi all,

I fuly agree, Ant projects are dead for me. I only use NB Maven projects since several years now and even if in the beginning the transition was not always easy when it came to customs builds, now you can do everything you need with Maven projects as you could with Ant AFAIK.

However, Ant project should still be kept for legacy projects and to run the examples you find in books dedicated to NB.

Finally, I would really vote to make the move from Ant to Maven to build Netbeans itself. We then no longer need no use and maintain the nam-repository-plugin.

Cheers,

JM Borer

> On 24 Nov 2018, at 08:53, Jaroslav Tulach <[hidden email]> wrote:
>
> Hi guys,
> the Apache NetBeans release 10 is (almost) finished and ready for download.
> Time to look forward: Long live Apache NetBeans - the UI for Apache Maven!
>
> NetBeans is known for its excellent Maven support. Time to bring it to new
> level - time to lead all NetBeans newbies directly into Maven hands:
>
> Whenever one creates new Java project from scratch a Maven project should be
> created.
>
> Currently the default project type is Ant based, but as Jesse Glick (the
> author of the Ant based projects integration) once asked: "Is anybody still
> using that!?" That is the question! Newcomers use it, but otherwise it is
> useless dead end road. Starting new Ant based project in a year 2018 is a
> nonsence!
>
> The current duality of Ant/Maven project support also wastes precious NetBeans
> development resources - features are usually implemented for Ant based
> projects first and only then ported to Maven. That's misfocused and upside
> down.
>
> Let's make the switch and offer Maven projects by default. Maven is well
> suited for the task: it is standard, well adopted build system. Maven comes
> with project archetypes that will serve as great starting templates for our
> newly generated project.
>
> What will change? Not the code, but the presentation: When one invokes "New
> Project" in NetBeans 11, there should be:
>
> Java:
>  - Java Application
>  - Java Frontend Application
>  - Project from Archetype
>  - POM Project
>  - NetBeans Application
>
> Ant(ic)/Java:
>  - Java Free-Form Project
>  - Java Modular Project
>  - Java Project with Existing Sources
>  - Java Class Library
>  - Java Application
>
> Ant(ic)/JavaFX:
>  - JavaFX Application
>  - JavaFX Preloader
>  - JavaFX FXML Application
>  - JavaFX in Swing Application
>  - JavaFX Project with Existing Sources
>
> Ant(ic)/NetBeans Modules:
>  - Module
>  - Module Suite
>  - Library Wrapper Module
>  - NetBeans Platform Application
>
> PHP:
>  // unchanged
>
> HTML5/JavaScript:
>  // unchanged
>
>
> The "Java" category will offer only Maven based projects. I hope this change
> will be welcomed by NetBeans as well as Maven supporters and will help Apache
> NetBeans to move forward and focus on support of technology that matters!
>
> Best regards and thanks in advance for your support.
> Jaroslav Tulach
> NetBeans founder & initial architect
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
> For further information about the NetBeans mailing lists, visit:
> https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
>
>
>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: NetBeans - the UI for Maven

Martin Desruisseaux
In reply to this post by Jaroslav Tulach
I think differently. In Apache SIS for example, we maintain both a Maven
and Ant project. The root source code directory is a classical Maven
project with pom.xml file [1], but we also maintain a sub-directory with
NetBeans Ant project configuration [2]. The official project
configuration is the Maven one, but the Ant project configuration is
keep in sync and takes its dependencies directly from the
~/.m2/repository directory. This means that the project needs to be
built with Maven once before we can use the Ant project. We do that for
the following reasons:

  * NetBeans Ant project builds faster.
  * Application and debugging sessions start faster in NetBeans Ant
    project. This is very convenient when we do a lot of "modify - test"
    cycles.
  * Allow to commit configurations that can not be done in Maven (header
    license, hints, additional words for check speller).
  * NetBeans Ant Jigsaw project configuration offers better
    compatibility with Jigsaw (more on it below).

A major issue is that since Jigsaw, Maven standard directory layout is
incompatible with java, javac and javadoc "--module-path" option, which
is making me look for alternatives (Gradle?). I describe the issue at
[3]. I would like to try changes in maven-compiler, maven-javadoc,
maven-jar and maven-deploy plugins for supporting Jigsaw, but did not
had the time to start yet. As far as I can see, I can not modularize my
projects the way I want with Maven at it stands today.

I also feel more concerned about Maven standard directory layout not
only because of its incompatibility with Jigsaw module paths, but also
because it does not seem well suited to project mixing two or more
languages. For example in the given directory layout:

  * src/main/java
  * src/main/cpp
  * src/main/resources

Does the resources applies to Java, to C++ or both?

So Maven is a great tool, but its speed is not yet the same than the
NetBeans Ant project configuration (admittedly it may be improved with
time) and - more importantly - I think that the Maven standard directory
layout needs to be modified at least for Jigsaw compatibility, maybe for
better multi-language support.

    Regards,

        Martin

[1] https://github.com/apache/sis
[2] https://github.com/apache/sis/tree/master/ide-project/NetBeans/nbproject
[3] https://github.com/Geomatys/maven-plugins/wiki

Reply | Threaded
Open this post in threaded view
|

Re: NetBeans - the UI for Maven

Jan Lahoda
Hi Martin,

I appreciate that your are using NetBeans - thanks for that!

But, as I understand Jarsolav's proposal, it only proposes to change the
presentation in the "New Project" dialog, so that the (more standard) Maven
projects would be ordered in front of/above the Ant projects. Users would
still be able to create the Ant projects, if they chose so; and of course
NetBeans would still be able to open existing Ant projects (and I don't
think we'd want or be able to drop the ability to open the Ant projects in
the foreseeable future).

So, I am +1 on this proposal.

On Sat, Nov 24, 2018 at 11:29 AM Martin Desruisseaux <
[hidden email]> wrote:

> I think differently. In Apache SIS for example, we maintain both a Maven
> and Ant project. The root source code directory is a classical Maven
> project with pom.xml file [1], but we also maintain a sub-directory with
> NetBeans Ant project configuration [2]. The official project
> configuration is the Maven one, but the Ant project configuration is
> keep in sync and takes its dependencies directly from the
> ~/.m2/repository directory. This means that the project needs to be
> built with Maven once before we can use the Ant project. We do that for
> the following reasons:
>
>   * NetBeans Ant project builds faster.
>   * Application and debugging sessions start faster in NetBeans Ant
>     project. This is very convenient when we do a lot of "modify - test"
>     cycles.
>   * Allow to commit configurations that can not be done in Maven (header
>     license, hints, additional words for check speller).
>   * NetBeans Ant Jigsaw project configuration offers better
>     compatibility with Jigsaw (more on it below).
>
> A major issue is that since Jigsaw, Maven standard directory layout is
> incompatible with java, javac and javadoc "--module-path" option, which
> is making me look for alternatives (Gradle?). I describe the issue at
> [3]. I would like to try changes in maven-compiler, maven-javadoc,
> maven-jar and maven-deploy plugins for supporting Jigsaw, but did not
> had the time to start yet. As far as I can see, I can not modularize my
> projects the way I want with Maven at it stands today.
>

FWIW, there is StandardJavaFileManager.setLocationForModule:
https://docs.oracle.com/javase/10/docs/api/javax/tools/StandardJavaFileManager.html#setLocationForModule(javax.tools.JavaFileManager.Location,java.lang.String,java.util.Collection)

which might be useful in some cases.

Jan


> I also feel more concerned about Maven standard directory layout not
> only because of its incompatibility with Jigsaw module paths, but also
> because it does not seem well suited to project mixing two or more
> languages. For example in the given directory layout:
>
>   * src/main/java
>   * src/main/cpp
>   * src/main/resources
>
> Does the resources applies to Java, to C++ or both?
>
> So Maven is a great tool, but its speed is not yet the same than the
> NetBeans Ant project configuration (admittedly it may be improved with
> time) and - more importantly - I think that the Maven standard directory
> layout needs to be modified at least for Jigsaw compatibility, maybe for
> better multi-language support.
>
>     Regards,
>
>         Martin
>
> [1] https://github.com/apache/sis
> [2]
> https://github.com/apache/sis/tree/master/ide-project/NetBeans/nbproject
> [3] https://github.com/Geomatys/maven-plugins/wiki
>
>
Reply | Threaded
Open this post in threaded view
|

Re: NetBeans - the UI for Maven

Enrico Olivelli
In reply to this post by Martin Desruisseaux
Martin,

Il sab 24 nov 2018, 11:29 Martin Desruisseaux <
[hidden email]> ha scritto:

> I think differently. In Apache SIS for example, we maintain both a Maven
> and Ant project. The root source code directory is a classical Maven
> project with pom.xml file [1], but we also maintain a sub-directory with
> NetBeans Ant project configuration [2]. The official project
> configuration is the Maven one, but the Ant project configuration is
> keep in sync and takes its dependencies directly from the
> ~/.m2/repository directory. This means that the project needs to be
> built with Maven once before we can use the Ant project. We do that for
> the following reasons:
>
>   * NetBeans Ant project builds faster.
>   * Application and debugging sessions start faster in NetBeans Ant
>     project. This is very convenient when we do a lot of "modify - test"
>     cycles.
>   * Allow to commit configurations that can not be done in Maven (header
>     license, hints, additional words for check speller).
>   * NetBeans Ant Jigsaw project configuration offers better
>     compatibility with Jigsaw (more on it below).
>
> A major issue is that since Jigsaw, Maven standard directory layout is
> incompatible with java, javac and javadoc "--module-path" option, which
> is making me look for alternatives (Gradle?). I describe the issue at
> [3]. I would like to try changes in maven-compiler, maven-javadoc,
> maven-jar and maven-deploy plugins for supporting Jigsaw, but did not
> had the time to start yet. As far as I can see, I can not modularize my
> projects the way I want with Maven at it stands today.
>
> I also feel more concerned about Maven standard directory layout not
> only because of its incompatibility with Jigsaw module paths, but also
> because it does not seem well suited to project mixing two or more
> languages. For example in the given directory layout:
>
>   * src/main/java
>   * src/main/cpp
>   * src/main/resources
>

Have you already shared your thoughts and needs with Apache Maven group ?

Cheers
Enrico


> Does the resources applies to Java, to C++ or both?
>
> So Maven is a great tool, but its speed is not yet the same than the
> NetBeans Ant project configuration (admittedly it may be improved with
> time) and - more importantly - I think that the Maven standard directory
> layout needs to be modified at least for Jigsaw compatibility, maybe for
> better multi-language support.
>
>     Regards,
>
>         Martin
>
> [1] https://github.com/apache/sis
> [2]
> https://github.com/apache/sis/tree/master/ide-project/NetBeans/nbproject
> [3] https://github.com/Geomatys/maven-plugins/wiki
>
> --


-- Enrico Olivelli
Reply | Threaded
Open this post in threaded view
|

Re: NetBeans - the UI for Maven

John McDonnell
+1 I like this idea of making Maven the default.

I'd also like to see if we could being Gradle support into the IDE by
default as well.  I know its worked on as a plugin but I think bringing it
into the standard distribution would be a nice plus to have in the IDE as
well.

Regards

John

On Sat, 24 Nov 2018 at 11:14, Enrico Olivelli <[hidden email]> wrote:

> Martin,
>
> Il sab 24 nov 2018, 11:29 Martin Desruisseaux <
> [hidden email]> ha scritto:
>
> > I think differently. In Apache SIS for example, we maintain both a Maven
> > and Ant project. The root source code directory is a classical Maven
> > project with pom.xml file [1], but we also maintain a sub-directory with
> > NetBeans Ant project configuration [2]. The official project
> > configuration is the Maven one, but the Ant project configuration is
> > keep in sync and takes its dependencies directly from the
> > ~/.m2/repository directory. This means that the project needs to be
> > built with Maven once before we can use the Ant project. We do that for
> > the following reasons:
> >
> >   * NetBeans Ant project builds faster.
> >   * Application and debugging sessions start faster in NetBeans Ant
> >     project. This is very convenient when we do a lot of "modify - test"
> >     cycles.
> >   * Allow to commit configurations that can not be done in Maven (header
> >     license, hints, additional words for check speller).
> >   * NetBeans Ant Jigsaw project configuration offers better
> >     compatibility with Jigsaw (more on it below).
> >
> > A major issue is that since Jigsaw, Maven standard directory layout is
> > incompatible with java, javac and javadoc "--module-path" option, which
> > is making me look for alternatives (Gradle?). I describe the issue at
> > [3]. I would like to try changes in maven-compiler, maven-javadoc,
> > maven-jar and maven-deploy plugins for supporting Jigsaw, but did not
> > had the time to start yet. As far as I can see, I can not modularize my
> > projects the way I want with Maven at it stands today.
> >
> > I also feel more concerned about Maven standard directory layout not
> > only because of its incompatibility with Jigsaw module paths, but also
> > because it does not seem well suited to project mixing two or more
> > languages. For example in the given directory layout:
> >
> >   * src/main/java
> >   * src/main/cpp
> >   * src/main/resources
> >
>
> Have you already shared your thoughts and needs with Apache Maven group ?
>
> Cheers
> Enrico
>
>
> > Does the resources applies to Java, to C++ or both?
> >
> > So Maven is a great tool, but its speed is not yet the same than the
> > NetBeans Ant project configuration (admittedly it may be improved with
> > time) and - more importantly - I think that the Maven standard directory
> > layout needs to be modified at least for Jigsaw compatibility, maybe for
> > better multi-language support.
> >
> >     Regards,
> >
> >         Martin
> >
> > [1] https://github.com/apache/sis
> > [2]
> > https://github.com/apache/sis/tree/master/ide-project/NetBeans/nbproject
> > [3] https://github.com/Geomatys/maven-plugins/wiki
> >
> > --
>
>
> -- Enrico Olivelli
>
Reply | Threaded
Open this post in threaded view
|

Re: NetBeans - the UI for Maven

rfscholte
In reply to this post by Martin Desruisseaux
On Sat, 24 Nov 2018 11:29:11 +0100, Martin Desruisseaux  
<[hidden email]> wrote:

> I think differently. In Apache SIS for example, we maintain both a Maven
> and Ant project. The root source code directory is a classical Maven
> project with pom.xml file [1], but we also maintain a sub-directory with
> NetBeans Ant project configuration [2]. The official project
> configuration is the Maven one, but the Ant project configuration is
> keep in sync and takes its dependencies directly from the
> ~/.m2/repository directory. This means that the project needs to be
> built with Maven once before we can use the Ant project. We do that for
> the following reasons:
>
>   * NetBeans Ant project builds faster.
>   * Application and debugging sessions start faster in NetBeans Ant
>     project. This is very convenient when we do a lot of "modify - test"
>     cycles.
>   * Allow to commit configurations that can not be done in Maven (header
>     license, hints, additional words for check speller).
>   * NetBeans Ant Jigsaw project configuration offers better
>     compatibility with Jigsaw (more on it below).
>
> A major issue is that since Jigsaw, Maven standard directory layout is
> incompatible with java, javac and javadoc "--module-path" option, which
> is making me look for alternatives (Gradle?). I describe the issue at
> [3]. I would like to try changes in maven-compiler, maven-javadoc,
> maven-jar and maven-deploy plugins for supporting Jigsaw, but did not
> had the time to start yet. As far as I can see, I can not modularize my
> projects the way I want with Maven at it stands today.

Let me correct this part: there is *no* need to change the folder  
structure to work with the Java Platform Modular System. The only thing  
you need to do is add a module-info.java to src/main/java and ensure  
you're using maven-compiler-plugin-3.8.0. That's it! Maven is the only  
tool that had proper integration before the release of Java 9.
The key library which might(/should!) be interesting for you is  
Plexus-Java [1], which calculates the modulepath.
For more details, just contact me.

thanks
Robert Scholte

[1]  
https://github.com/codehaus-plexus/plexus-languages/tree/master/plexus-java


>
> I also feel more concerned about Maven standard directory layout not
> only because of its incompatibility with Jigsaw module paths, but also
> because it does not seem well suited to project mixing two or more
> languages. For example in the given directory layout:
>
>   * src/main/java
>   * src/main/cpp
>   * src/main/resources
>
> Does the resources applies to Java, to C++ or both?
>
> So Maven is a great tool, but its speed is not yet the same than the
> NetBeans Ant project configuration (admittedly it may be improved with
> time) and - more importantly - I think that the Maven standard directory
> layout needs to be modified at least for Jigsaw compatibility, maybe for
> better multi-language support.
>
>     Regards,
>
>         Martin
>
> [1] https://github.com/apache/sis
> [2]  
> https://github.com/apache/sis/tree/master/ide-project/NetBeans/nbproject
> [3] https://github.com/Geomatys/maven-plugins/wiki

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: NetBeans - the UI for Maven

Martin Desruisseaux
Hello Robert

Thanks for your reply.

Le 24/11/2018 à 12:36, Robert Scholte a écrit :

> Let me correct this part: there is *no* need to change the folder
> structure to work with the Java Platform Modular System. The only
> thing you need to do is add a module-info.java to src/main/java and
> ensure you're using maven-compiler-plugin-3.8.0. That's it!
>
My email was saying that there is a need to change the folder structure
for using Java Platform Modular System with "--module-path" options. The
key part is "--module-path". What maven-compiler-plugin-3.8.0 does is to
use the "--class-path" options, which are the legacy options before Jigsaw.

The consequence is that it is currently not possible to build more than
one Jigsaw module in a single invocation of "javac", "javadoc", "jlink"
or other JDK tools with Maven. Consequently I'm not aware of any way to
generate a multi-modules javadoc, or to execute annotation processors
using information from more than one module (except by generating
temporary files), or any other task for which there is advantages in
being able to use standard JDK tools with their new "--module-path" options.

What I want is to be able to use Maven with Java "--module-path" options
instead than "--class-path". This is where the Maven standard directory
layout become an obstacle, because the "--module-path" option imposes a
directory layout which is different than the Maven's one.

I realize that not everyone may want to build a multi-modular project
using "--module-path" option. But before Java 9, Maven made the use of
javac easier without blocking the use of other options when desired.
Since Java 9, we have a difficulty for which I have not yet found a
satisfying solution other than the proposed Maven changes.


> The key library which might(/should!) be interesting for you is
> Plexus-Java [1], which calculates the modulepath.

I have not looked in details to Plexus-Java. Does it create a path for
each Maven module? That would be a workaround, but it still more
complicated than using Jigsaw in its "natural" way.

    Martin



---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: NetBeans - the UI for Maven

Martin Desruisseaux
In reply to this post by Enrico Olivelli
Hello Enrico

Le 24/11/2018 à 12:13, Enrico Olivelli a écrit :

> Have you already shared your thoughts and needs with Apache Maven group ?
>
Yes, on the mailing list. My feeling is that in order to be convincing,
I need to create a prototype showing the feasibility of my proposal.
This is the intent of https://github.com/Geomatys/maven-plugins - now I
need to find time to work on it.

    Martin



---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: NetBeans - the UI for Maven

Martin Desruisseaux
In reply to this post by Jan Lahoda
Hello Jan

Le 24/11/2018 à 12:12, Jan Lahoda a écrit :

> FWIW, there is StandardJavaFileManager.setLocationForModule:
> https://docs.oracle.com/javase/10/docs/api/javax/tools/StandardJavaFileManager.html#setLocationForModule(javax.tools.JavaFileManager.Location,java.lang.String,java.util.Collection)
> which might be useful in some cases.
>
Thanks, I was not aware of this method. It may indeed be useful for (if
I understood correctly) plugins invoking the compiler from Java code. I
will keep that in mind if I have a chance to do experiments.

    Martin



---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: NetBeans - the UI for Maven

rfscholte
In reply to this post by Martin Desruisseaux
On Sat, 24 Nov 2018 13:28:28 +0100, Martin Desruisseaux  
<[hidden email]> wrote:

> Hello Robert
>
> Thanks for your reply.
>
> Le 24/11/2018 à 12:36, Robert Scholte a écrit :
>
>> Let me correct this part: there is *no* need to change the folder
>> structure to work with the Java Platform Modular System. The only
>> thing you need to do is add a module-info.java to src/main/java and
>> ensure you're using maven-compiler-plugin-3.8.0. That's it!
>>
> My email was saying that there is a need to change the folder structure
> for using Java Platform Modular System with "--module-path" options. The
> key part is "--module-path". What maven-compiler-plugin-3.8.0 does is to
> use the "--class-path" options, which are the legacy options before  
> Jigsaw.
>
> The consequence is that it is currently not possible to build more than
> one Jigsaw module in a single invocation of "javac", "javadoc", "jlink"
> or other JDK tools with Maven. Consequently I'm not aware of any way to
> generate a multi-modules javadoc, or to execute annotation processors
> using information from more than one module (except by generating
> temporary files), or any other task for which there is advantages in
> being able to use standard JDK tools with their new "--module-path"  
> options.

With the Java Platform Modular System you'll clearly see different  
requirements between library and application developers.
Keep in mind that 1 pom-file can represent only 1 module. If you want to  
distribute multiple modules, you will still need a multimodule Maven  
project.
Single invocation only makes sense for an application that won't share  
modules. Up until know there's only 1 such large application: the JDK  
itself (it is not really sharing modules, modules are part of the  
application)
So yes: single invocation is an option for the jdk tools but doesn't fit  
in the Maven architecture and is probably in general not that needed.  
There are no plans to make these changes in Maven.
As response Remi Forax wrote Pro[1], which is build upon these new jdk  
tools features combined with the concepts of Maven.

[1] https://github.com/forax/pro

>
> What I want is to be able to use Maven with Java "--module-path" options
> instead than "--class-path". This is where the Maven standard directory
> layout become an obstacle, because the "--module-path" option imposes a
> directory layout which is different than the Maven's one.

No, module-path is not the issue, but module-source-path is, which expects  
an extra folder reflection the module-name.

>
> I realize that not everyone may want to build a multi-modular project
> using "--module-path" option. But before Java 9, Maven made the use of
> javac easier without blocking the use of other options when desired.
> Since Java 9, we have a difficulty for which I have not yet found a
> satisfying solution other than the proposed Maven changes.

I don't understand this issue. As a java developer wanting to add module  
descriptor, you only have to create src/main/java/module-info.java. You  
can build your project as you are used to.

>
>
>> The key library which might(/should!) be interesting for you is
>> Plexus-Java [1], which calculates the modulepath.
>
> I have not looked in details to Plexus-Java. Does it create a path for
> each Maven module? That would be a workaround, but it still more
> complicated than using Jigsaw in its "natural" way.
>
>     Martin
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: NetBeans - the UI for Maven

Martin Desruisseaux
In reply to this post by Martin Desruisseaux
Le 24/11/2018 à 13:28, Martin Desruisseaux a écrit :
> The key part is "--module-path".

Sorry I mean "--module-source-path" for the compilation and javadoc
generation parts. Likewise I mean "--source-path" instead of
"--classpath" for compilation with pre-jigsaw options.

    Martin



---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: NetBeans - the UI for Maven

Martin Desruisseaux
In reply to this post by rfscholte
Le 24/11/2018 à 13:53, Robert Scholte a écrit :

> With the Java Platform Modular System you'll clearly see different
> requirements between library and application developers.
>
Indeed (e.g. jlink is for application developers), but the requirements
I'm talking about are for library developers.


> Keep in mind that 1 pom-file can represent only 1 module. If you want
> to distribute multiple modules, you will still need a multimodule
> Maven project.
>
Yes and no. 1 pom-file can represent only one artifact. But the rest of
the discussion assumed that 1 artifact = 1 module, or that 1 Maven
module = 1 Jigsaw module. This relationship does not necessarily hold.
From recent discussion on OpenJDK public mailing list [1]:

    I'm sure the topic of executable modular JARs files be back on the
    table some day but it needs to be looked at in conjunction with the
    issues around having multiple modules in the same artifact. They
    would be likely be work needed in several Maven plugins and other
    parts of the eco system too.  In the mean-time, it's not too hard to
    package multiple modules into the same JAR file and have a main
    class that creates a configuration and module layer from the modules
    in the JAR files.

Another possibility is to generate the pom.xml files for each Jigsaw
module, by intersecting the parent pom.xml with module-info.


> Single invocation only makes sense for an application that won't share
> modules.
>
No - a single javac invocation on a multi-modules projects still
generate .class files in separated directories for each Jigsaw module,
which result in one JAR file per module. I good demonstration of that is
NetBeans modular projects (based on Ant), which does exactly that. I
would like to see the same capability in Maven.


> So yes: single invocation is an option for the jdk tools but doesn't
> fit in the Maven architecture and is probably in general not that needed.
>
It does not fit with Maven standard directory layout. But with a change
of layout and corresponding changes in Maven plugins, I do not see major
obstacle (but of course I do not have your deep knowledge of Maven
internal). However I would not said that this is generally not needed.
We have at least MJAVADOC-449. Together with other issues, for me the
choice is between an evolution of Maven (possibly with custom plugins)
or migrating to another build system. Furthermore other Jigsaw evolution
may come (e.g. above-cited multiple modules in same artifact). If Maven
does not become more Jigsaw-friendly, the amount of difficulties may
increase in the future.


> There are no plans to make these changes in Maven.
>
> As response Remi Forax wrote Pro[1], which is build upon these new jdk
> tools features combined with the concepts of Maven.
>
Yes I'm aware of that, and my proposal is in part bringing some of Remi
Forax's idea into Maven.


> No, module-path is not the issue, but module-source-path is, which
> expects an extra folder reflection the module-name.
>
Indeed - this is the correction email I posted after my previous email.


> I don't understand this issue. As a java developer wanting to add
> module descriptor, you only have to create
> src/main/java/module-info.java. You can build your project as you are
> used to.
>
Adding module-info.java is sufficient for generating the JAR file, but
this is not the end of development process. We also needs to generate
javadoc. We sometime want to run annotation processing tools. Those
extra tasks are where difficulties arise. There is also a circular
dependency problem that would be solved with my proposal, but this one
is admittedly quite specific to a project.

    Martin


[1] http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-November/056839.html
[2] https://issues.apache.org/jira/browse/MJAVADOC-449

Reply | Threaded
Open this post in threaded view
|

Re: NetBeans - the UI for Maven

rfscholte
On Sat, 24 Nov 2018 15:02:08 +0100, Martin Desruisseaux  
<[hidden email]> wrote:

> Le 24/11/2018 à 13:53, Robert Scholte a écrit :
>
>> With the Java Platform Modular System you'll clearly see different
>> requirements between library and application developers.
>>
> Indeed (e.g. jlink is for application developers), but the requirements
> I'm talking about are for library developers.
>
>
>> Keep in mind that 1 pom-file can represent only 1 module. If you want
>> to distribute multiple modules, you will still need a multimodule
>> Maven project.
>>
> Yes and no. 1 pom-file can represent only one artifact. But the rest of
> the discussion assumed that 1 artifact = 1 module, or that 1 Maven
> module = 1 Jigsaw module. This relationship does not necessarily hold.
> From recent discussion on OpenJDK public mailing list [1]:
>
>     I'm sure the topic of executable modular JARs files be back on the
>     table some day but it needs to be looked at in conjunction with the
>     issues around having multiple modules in the same artifact. They
>     would be likely be work needed in several Maven plugins and other
>     parts of the eco system too.  In the mean-time, it's not too hard to
>     package multiple modules into the same JAR file and have a main
>     class that creates a configuration and module layer from the modules
>     in the JAR files.
>
> Another possibility is to generate the pom.xml files for each Jigsaw
> module, by intersecting the parent pom.xml with module-info.
>

There is no clean way to do this yet.

>
>> Single invocation only makes sense for an application that won't share
>> modules.
>>
> No - a single javac invocation on a multi-modules projects still
> generate .class files in separated directories for each Jigsaw module,
> which result in one JAR file per module. I good demonstration of that is
> NetBeans modular projects (based on Ant), which does exactly that. I
> would like to see the same capability in Maven.
>
>
>> So yes: single invocation is an option for the jdk tools but doesn't
>> fit in the Maven architecture and is probably in general not that  
>> needed.
>>
> It does not fit with Maven standard directory layout. But with a change
> of layout and corresponding changes in Maven plugins, I do not see major
> obstacle (but of course I do not have your deep knowledge of Maven
> internal). However I would not said that this is generally not needed.
> We have at least MJAVADOC-449. Together with other issues, for me the
> choice is between an evolution of Maven (possibly with custom plugins)
> or migrating to another build system. Furthermore other Jigsaw evolution
> may come (e.g. above-cited multiple modules in same artifact). If Maven
> does not become more Jigsaw-friendly, the amount of difficulties may
> increase in the future.
>
>

Today I started looking at MJAVADOC-449 again and it seems that just  
nobody took serious time to solve this.
I've been able to create the proper commandline by moving some classpath  
entries to the modulepath.
Now it is a matter of implementing this.

>> There are no plans to make these changes in Maven.
>>
>> As response Remi Forax wrote Pro[1], which is build upon these new jdk
>> tools features combined with the concepts of Maven.
>>
> Yes I'm aware of that, and my proposal is in part bringing some of Remi
> Forax's idea into Maven.

I'll wait for the PRs :)

>
>
>> No, module-path is not the issue, but module-source-path is, which
>> expects an extra folder reflection the module-name.
>>
> Indeed - this is the correction email I posted after my previous email.
>
>
>> I don't understand this issue. As a java developer wanting to add
>> module descriptor, you only have to create
>> src/main/java/module-info.java. You can build your project as you are
>> used to.
>>
> Adding module-info.java is sufficient for generating the JAR file, but
> this is not the end of development process. We also needs to generate
> javadoc. We sometime want to run annotation processing tools. Those
> extra tasks are where difficulties arise. There is also a circular
> dependency problem that would be solved with my proposal, but this one
> is admittedly quite specific to a project.
>
>     Martin
>
>
> [1]  
> http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-November/056839.html
> [2] https://issues.apache.org/jira/browse/MJAVADOC-449

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: NetBeans - the UI for Maven

Martin Desruisseaux
Le 24/11/2018 à 15:10, Robert Scholte a écrit :

> Today I started looking at MJAVADOC-449 again and it seems that just
> nobody took serious time to solve this. I've been able to create the
> proper commandline by moving some classpath entries to the modulepath.
> Now it is a matter of implementing this.
>
Great, thanks!

Indeed, this is what I described in
https://github.com/Geomatys/maven-plugins/wiki#changes-to-maven-plugins
- that implementing this functionality seems basically a matter of
replacing some "--classpath" by "--module-path" and some "--source-path"
by "--module-source-path" options. However while Javadoc is currently
the main issue, the same capability is desirable for other tools too,
which is why I would like to address this issue at a more fundamental
level (the directory layout).


>>> As response Remi Forax wrote Pro[1], which is build upon these new jdk
>>>
>>> tools features combined with the concepts of Maven.
>>>
>> Yes I'm aware of that, and my proposal is in part bringing some of Remi
>>
>> Forax's idea into Maven.
>>
> I'll wait for the PRs :)
>
Cool! I don't know yet when I will have time to start my experiment, but
I would let you know when I will have a proposal that can be shown.

    Martin



---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: NetBeans - the UI for Maven

rfscholte
On Sat, 24 Nov 2018 15:34:51 +0100, Martin Desruisseaux  
<[hidden email]> wrote:

> Le 24/11/2018 à 15:10, Robert Scholte a écrit :
>
>> Today I started looking at MJAVADOC-449 again and it seems that just
>> nobody took serious time to solve this. I've been able to create the
>> proper commandline by moving some classpath entries to the modulepath.
>> Now it is a matter of implementing this.
>>
> Great, thanks!
>
> Indeed, this is what I described in
> https://github.com/Geomatys/maven-plugins/wiki#changes-to-maven-plugins
> - that implementing this functionality seems basically a matter of
> replacing some "--classpath" by "--module-path" and some "--source-path"
> by "--module-source-path" options. However while Javadoc is currently
> the main issue, the same capability is desirable for other tools too,
> which is why I would like to address this issue at a more fundamental
> level (the directory layout).
>

If you are fine with tool invocations per module, then there's no need to  
change the directory layout. The current layout will stay the default and  
you can already apply module descriptors. And I expect that this is good  
enough for the majority of the community.

**If And Only If** you want to make use of single tool invocation for all  
you JPMS modules, then you cannot use Maven, it's architecture doesn't  
support it and any plugin trying to solve this is a hack.

Might be possible to add support for it in Maven 4 or 5, but focus is on  
other improvements that block us right now.

Robert

>
>>>> As response Remi Forax wrote Pro[1], which is build upon these new jdk
>>>>
>>>> tools features combined with the concepts of Maven.
>>>>
>>> Yes I'm aware of that, and my proposal is in part bringing some of Remi
>>>
>>> Forax's idea into Maven.
>>>
>> I'll wait for the PRs :)
>>
> Cool! I don't know yet when I will have time to start my experiment, but
> I would let you know when I will have a proposal that can be shown.
>
>     Martin
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: NetBeans - the UI for Maven

Javier Ortiz
Sounds good to me. I would also suggest that the Gradle plugin should be
part of the base IDE.

I don't thin Maven in classroom is an issue. In ANT they need to download
dependencies as well. In those cases they can install locally from the
provided ones.

On Sat, Nov 24, 2018, 9:44 AM Robert Scholte <[hidden email] wrote:

> On Sat, 24 Nov 2018 15:34:51 +0100, Martin Desruisseaux
> <[hidden email]> wrote:
>
> > Le 24/11/2018 à 15:10, Robert Scholte a écrit :
> >
> >> Today I started looking at MJAVADOC-449 again and it seems that just
> >> nobody took serious time to solve this. I've been able to create the
> >> proper commandline by moving some classpath entries to the modulepath.
> >> Now it is a matter of implementing this.
> >>
> > Great, thanks!
> >
> > Indeed, this is what I described in
> > https://github.com/Geomatys/maven-plugins/wiki#changes-to-maven-plugins
> > - that implementing this functionality seems basically a matter of
> > replacing some "--classpath" by "--module-path" and some "--source-path"
> > by "--module-source-path" options. However while Javadoc is currently
> > the main issue, the same capability is desirable for other tools too,
> > which is why I would like to address this issue at a more fundamental
> > level (the directory layout).
> >
>
> If you are fine with tool invocations per module, then there's no need to
> change the directory layout. The current layout will stay the default and
> you can already apply module descriptors. And I expect that this is good
> enough for the majority of the community.
>
> **If And Only If** you want to make use of single tool invocation for all
> you JPMS modules, then you cannot use Maven, it's architecture doesn't
> support it and any plugin trying to solve this is a hack.
>
> Might be possible to add support for it in Maven 4 or 5, but focus is on
> other improvements that block us right now.
>
> Robert
>
> >
> >>>> As response Remi Forax wrote Pro[1], which is build upon these new jdk
> >>>>
> >>>> tools features combined with the concepts of Maven.
> >>>>
> >>> Yes I'm aware of that, and my proposal is in part bringing some of Remi
> >>>
> >>> Forax's idea into Maven.
> >>>
> >> I'll wait for the PRs :)
> >>
> > Cool! I don't know yet when I will have time to start my experiment, but
> > I would let you know when I will have a proposal that can be shown.
> >
> >     Martin
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [hidden email]
> > For additional commands, e-mail: [hidden email]
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
> For further information about the NetBeans mailing lists, visit:
> https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
>
>
>
>
Reply | Threaded
Open this post in threaded view
|

Re: NetBeans - the UI for Maven

Martin Desruisseaux
In reply to this post by rfscholte
Le 24/11/2018 à 16:39, Robert Scholte a écrit :

> **If And Only If** you want to make use of single tool invocation for
> all you JPMS modules, then you cannot use Maven, it's architecture
> doesn't support it and any plugin trying to solve this is a hack.
>
But isn't what you are going to do for fixing MJAVADOC-449 (aggregated
javadoc), or is there another way?


> Might be possible to add support for it in Maven 4 or 5, but focus is
> on other improvements that block us right now.
>
Understood. Thanks!

    Martin



---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: NetBeans - the UI for Maven

rfscholte
On Sat, 24 Nov 2018 17:02:02 +0100, Martin Desruisseaux  
<[hidden email]> wrote:

> Le 24/11/2018 à 16:39, Robert Scholte a écrit :
>
>> **If And Only If** you want to make use of single tool invocation for
>> all you JPMS modules, then you cannot use Maven, it's architecture
>> doesn't support it and any plugin trying to solve this is a hack.
>>
> But isn't what you are going to do for fixing MJAVADOC-449 (aggregated
> javadoc), or is there another way?
>

Aggregated reports have always been a single invocation, modularized or  
not.
Btw, MJAVADOC-449 has been fixed. Looking at some other issues before  
preparing a release.

thanks,
Robert

>
>> Might be possible to add support for it in Maven 4 or 5, but focus is
>> on other improvements that block us right now.
>>
> Understood. Thanks!
>
>     Martin
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

12