This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
When creating a standard Maven project via "File>New Project>Maven>Java Application", the new project appears to be generated with a variation of the venerable maven-quickstart archetype. This archetype has some shortcomings which make it not a good choice these days: - Like Ant projects, Maven projects should have separate options for java libraries and java applications, since their requirements are different. - The current archetype contains a JUnit dependency and test framework. Selection of a test framework (if any) should be left to the user, and is added anyway when using the IDE to create tests. - The source/binary format is the Maven default (JDK 1.5, which came out 9 years ago). This can be bumped to 1.7 (or at least 1.6) by now since the newer JDKs are much more fun. My vote is that 1.7 should be the default, since the IDE requires at least 1.7 now anyway. - The java files are formatted c++ style, and with some bizarre choices (another issue I've been meaning to file is that the generated files aren't reformatted). - New applications have a main class, but it is not set in Netbeans metadata. Make things easier for newbies to get started. - For applications, an additional "standalone" JAR file should be created. This jar should be executable and include dependencies. Once again, easier for newbies. - For libraries, javadocs should be generated and included by default when building the artifact and deploying to a repository. - The "pom.xml" file should contain an easy way to include the source code when deploying the artifact to a repository (disabled by default). If you really want to get fancy, this could be turned on if the user selects GPL or similar licenses. The current "Java Application" Maven project type should be broken up into "Java Application" and "Java Class Library" to match Ant projects, and more appropriate archetypes should be used. I've already created archetypes which address these issues. You're welcome to base your archetypes on them, or use them outright. I'll attach them tomorrow after I've sanitized them.
Created attachment 133780 [details] better archetypes In the attached archetypes, the plugin to include a source jar when deploying is simply commented out. It may be more elegant to use a build profile instead.
in general I believe we maintain way too many achetypes on our own, not sure if it's worth the effort to add another 2 to the mix. The general rule of thumb here is that as little content in archetype as possible is the best approach. Anything else basically means we a big portion of people will have to delete the stuff we added in good faith.. Netbeans module development archetypes can serve as example here. Another dimension of the problem is that most of the time, newly created projects inherit a big chunk of configuration from parent poms and archetypes cannot handle that well. Another option is to create the projects from scratch in the IDE directly, but that's more work. In the past then Ant based project have always been considered the first choice for people who are clueless about the build system. That's why we have a special Maven category in the new project wizard. Maven support has been always targeted at users who know what they are doing. Dumbing it down might make the experience worse for these people (just something to consider, I'm not claiming anything of this applies here) (In reply to comment #0) > > - The source/binary format is the Maven default (JDK 1.5, which came out 9 > years ago). This can be bumped to 1.7 (or at least 1.6) by now since the newer > JDKs are much more fun. My vote is that 1.7 should be the default, since the > IDE requires at least 1.7 now anyway. more or less a good idea jdk 1.5 is indeed old. not sure we want to maintain a special > - The java files are formatted c++ style, and with some bizarre choices > (another issue I've been meaning to file is that the generated files aren't > reformatted). Not really something we can easily tackle with archetype based project templates. > - New applications have a main class, but it is not set in Netbeans metadata. > Make things easier for newbies to get started. Well, on first invocation it will ask you about the main class and set it either temporarily or permanently. If we set the main class initially, then people will expect we change that on refactorings and also write it to manifest/pom and keep it in synch... too much work with little payoff. > - For applications, an additional "standalone" JAR file should be created. This > jar should be executable and include dependencies. Once again, easier for > newbies. See above my comment about dumbing down. I don't mind adding the support as some sort of optional piece of UI, but including it by default will just force a large portion of the userbase to delete it manually after creation. > - For libraries, javadocs should be generated and included by default when > building the artifact and deploying to a repository. > - The "pom.xml" file should contain an easy way to include the source code when > deploying the artifact to a repository (disabled by default). If you really > want to get fancy, this could be turned on if the user selects GPL or similar > licenses. That's something that has to be configured? both javadoc and source jars are included when you perform a release. if you want to include it with snapshots deployed to repository you just include the additional goal to the execution. > > The current "Java Application" Maven project type should be broken up into > "Java Application" and "Java Class Library" to match Ant projects, and more > appropriate archetypes should be used. 100% match to ant projects is not necessary, we have different audience I believe.
Very good points which make me realize I don't know Maven (and Netbeans) as well as I thought I did, although your argument for dumbing down the archetypes supports my position that JUnit should also be removed. Instead, how about just deviating from the current quickstart variant to: - set JDK 7 - remove the JUnit stuff I assume you're already maintaining an archetype because the encoding is set to UTF-8. As for the JDK suggestion, good practice dictates that you need to set the compiler plugin version, which may indeed conflict with a parent POM. Any ideas, or is this the reason it hasn't been set previously? The second item would make the archetype even simpler. Besides, JUnit 3? -- ...formatting... > Not really something we can easily tackle with archetype based project > templates. I know that Source>Format now works with files you select in the project view. You can't run it through that? ...main class... > Well, on first invocation it will ask you about the main class and set it > either temporarily or permanently. I forgot about that! no need for it to be in the archetype at all. ...include docs/sources... > That's something that has to be configured? both javadoc and source jars are > included when you perform a release. I did not know that! so when you deploy to a repository, if it's not a snapshot version it includes the javadocs and source jars? What if the the javadocs haven't yet been compiled? What if you don't want the sources to be deployed? Why do many artifacts in repos infuriatingly not have javadocs?
also related to jglick's issue 208462
(In reply to comment #3) > ...include docs/sources... > > That's something that has to be configured? both javadoc and source jars are > > included when you perform a release. > I did not know that! so when you deploy to a repository, if it's not a snapshot > version it includes the javadocs and source jars? What if the the javadocs > haven't yet been compiled? What if you don't want the sources to be deployed? > Why do many artifacts in repos infuriatingly not have javadocs? please note that "mvn deploy" will not include the javadoc/sources.. mvn release:prepare + mvn release:perform will.. I think mvn package javadoc:jar source:jar deploy might upload the javadoc+source jars as well.
Yup, marking as a dup of issue 208462. *** This bug has been marked as a duplicate of bug 208462 ***
(In reply to comment #5) > please note that "mvn deploy" will not include the javadoc/sources mvn -Prelease-profile deploy (In reply to comment #3) > I assume you're already maintaining an archetype > because the encoding is set to UTF-8. This is defined in the quickstart archetype I think.