Re: NetBeans - the UI for Maven
I think a preference for the default tool would make sense. Or even if it just remembered your last selection so you don’t have to keep changing it. The initial default should be Maven at this point, but maybe it could be Gradle if it ever becomes a first class citizen. I also agree with Tim, that forcing extra clicks and decisions should be avoided. So simply having an already filled in default option that can be safely ignored seems reasonable. Pick a project type, enter a name on the same screen where it shows you what build tool will be used (and where you have the *option* to change it), maybe fill in a main class if the project type is Java Application, then click done. How plug-ins can integrate with this wizard should be considered. I.e. before Gradle has first class out of the box support it should still be an option if the Gradle plugin is present. Regards. Scott - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: NetBeans - the UI for Maven
On Sat, 24 Nov 2018 17:02:02 +0100, Martin Desruisseaux 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: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: NetBeans - the UI for Maven
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: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: NetBeans - the UI for Maven
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 On Sat, 24 Nov 2018 15:34:51 +0100, Martin Desruisseaux > 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: users-unsubscr...@maven.apache.org > > For additional commands, e-mail: users-h...@maven.apache.org > > - > To unsubscribe, e-mail: dev-unsubscr...@netbeans.incubator.apache.org > For additional commands, e-mail: dev-h...@netbeans.incubator.apache.org > > For further information about the NetBeans mailing lists, visit: > https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists > > > >
Re: NetBeans - the UI for Maven
On Sat, 24 Nov 2018 15:34:51 +0100, Martin Desruisseaux 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: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: NetBeans - the UI for Maven
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: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: NetBeans - the UI for Maven
On Sat, 24 Nov 2018 15:02:08 +0100, Martin Desruisseaux 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: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: NetBeans - the UI for Maven
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
Re: NetBeans - the UI for Maven
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: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: NetBeans - the UI for Maven
On Sat, 24 Nov 2018 13:28:28 +0100, Martin Desruisseaux 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: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: NetBeans - the UI for Maven
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: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: NetBeans - the UI for Maven
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: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: NetBeans - the UI for Maven
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: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: NetBeans - the UI for Maven
On Sat, 24 Nov 2018 11:29:11 +0100, Martin Desruisseaux 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: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: NetBeans - the UI for Maven
+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 wrote: > Martin, > > Il sab 24 nov 2018, 11:29 Martin Desruisseaux < > martin.desruisse...@geomatys.com> 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 >
Re: NetBeans - the UI for Maven
Martin, Il sab 24 nov 2018, 11:29 Martin Desruisseaux < martin.desruisse...@geomatys.com> 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
Re: NetBeans - the UI for Maven
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 < martin.desruisse...@geomatys.com> 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 > >
Re: NetBeans - the UI for Maven
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 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: dev-unsubscr...@netbeans.incubator.apache.org > For additional commands, e-mail: dev-h...@netbeans.incubator.apache.org > > For further information about the NetBeans mailing lists, visit: > https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists > > > - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: NetBeans - the UI for Maven
Great idea. On Sat, Nov 24, 2018, 11:53 AM 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: dev-unsubscr...@netbeans.incubator.apache.org > For additional commands, e-mail: dev-h...@netbeans.incubator.apache.org > > For further information about the NetBeans mailing lists, visit: > https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists > > > >
Re: NetBeans - the UI for Maven
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
