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.
Product Version: NetBeans IDE Dev (Build 201008260001) Java: 1.6.0_20; Java HotSpot(TM) 64-Bit Server VM 16.3-b01-279 System: Mac OS X version 10.5.8 running on x86_64; MacRoman; en_US (nb) Running with GF 3.0.1 from my 6.9 install dir registered. Dependencies to both artifacts in the central repository and to open projects seem to not work. Open a Web App project and build it and you'll get: Failed to execute goal org.apache.maven.plugins:maven-compiler-plugin:2.3.1:compile (default-compile) on project MvnWebApp: Execution default-compile of goal org.apache.maven.plugins:maven-compiler-plugin:2.3.1:compile failed: Plugin org.apache.maven.plugins:maven-compiler-plugin:2.3.1 or one of its dependencies could not be resolved: Missing: ---------- 1) javax:javaee-endorsed-api:jar:6.0 Create quickstart archtype TestMvnLibPrj, add it as dependency to TestMvnPrj, build TestMvnPrj and you'll get the same: Failed to execute goal on project MvnTestProj: Missing: ---------- 1) com.mycompany:TestMvnLibPrj:jar:1.0-SNAPSHOT
The workaround for the WebApp case is to add the following to the pom file: <pluginRepositories> <pluginRepository> <id>java.net2</id> <name>Repository hosting the jee6 artifacts</name> <url>http://download.java.net/maven/2</url> </pluginRepository> </pluginRepositories>
(In reply to comment #0) > Create quickstart archtype TestMvnLibPrj, add it as dependency to TestMvnPrj, > build TestMvnPrj and you'll get the same: > > Failed to execute goal on project MvnTestProj: Missing: > ---------- > 1) com.mycompany:TestMvnLibPrj:jar:1.0-SNAPSHOT You need to build the library project first. (If they are in the same aggregator parent you can use 'Build with Dependencies', but not if they are just in unrelated projects.) (In reply to comment #1) > The workaround for the WebApp case is to add the following to the pom file: > <pluginRepositories> > <pluginRepository> > <id>java.net2</id> > <name>Repository hosting the jee6 artifacts</name> > <url>http://download.java.net/maven/2</url> > </pluginRepository> > </pluginRepositories> That's not a workaround, that's what you need to do. Otherwise Maven has no way of finding this artifact (unless you happen to already have it in your local repository).
(In reply to comment #1) > The workaround for the WebApp case is to add the following to the pom file: > <pluginRepositories> > <pluginRepository> > <id>java.net2</id> > <name>Repository hosting the jee6 artifacts</name> > <url>http://download.java.net/maven/2</url> > </pluginRepository> > </pluginRepositories> I think reporter was actually seeing something else; the existing Java EE 6 Web App archetype has this <dependency> listed under the compiler plugin, but that might not be enough. http://jira.codehaus.org/browse/MARCHETYPES-35 would solve the issue in a better way (will integrate into IDE when published). One workaround would be to add javax:javaee-endorsed-api:jar:6.0 as a regular dep to the project and build (could then delete the dep). Probably worked by accident in Maven 2 because the dep, even though expressed as a dep of the plugin rather than the project (which is nonsense), was resolved from regular repositories rather than plugin repositories. https://cwiki.apache.org/MAVEN/maven-3x-compatibility-notes.html#Maven3.xCompatibilityNotes-PluginRepositories shows that Maven 3 no longer allows this hack.
I'm going to reopen this to keep track of it because, regardless of whether the bug is in maven archetype or not, it is something we need to deal with in NB. If the archetype serves up uncompilable projects we have to either work around it (add the JAR as a dependency by default during project creation post-processing) or do something to make the project template less visible/suggest fix for user. I realize we can't guarantee the validity of all project archetypes but ones we offer in the new project wizard must work out of the box.
I am trying out with the latest build, and suddenly this works fine. How is this possible? Was there a fix that I missed?
Created attachment 101894 [details] Patch for Maven archetypes Sorry, my fault, still reproducible with a clean local Maven repository. I am attaching a patch for the archetypes that I tested locally. (Plus, also the version would need to be bumped, of course.)
Sorry, please disregard my patch, now I see Jesse already submitted one to http://jira.codehaus.org/browse/MARCHETYPES-35.
When fix of #MARCHETYPES-35 is applied on the archetypes, the new release of archetypes must resolve also #MARCHETYPES-36 (see issue 190033).
Staged a release of the new archetypes; will try to promote by Monday.
Workarounds exist -> not P1.
Thanks Jesse. One other change we will want to do in the archetype is to remove the reference to the java.net Maven repository, once the javaee-endorsed-api artefact has been uploaded to central, as requested here: https://issues.sonatype.org/browse/OSSRH-811 Not sure if we want to hold the release of the archetype for that, or do another minor release when this happens.
(In reply to comment #11) > Not sure if we want to hold the release of the archetype for that, or do > another minor release when this happens. Do another minor release, I think.
core-main #f5d346bba76f