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.
org.netbeans.junit.NbModuleSuite$S@3904bcf6(org.netbeans.junit.NbModuleSuite$S) Time elapsed: 2.381 sec <<< ERROR! java.io.IOException: no match for org.sonatype.sisu:sisu-guice:3.1.0 found in /home/local/CORPNET/chrlse/.m2/repository/org/sonatype/sisu/sisu-guice/3.1.0/sisu-guice-3.1.0-no_aop.jar: at org.netbeans.junit.NbModuleSuite$S.rewrite(NbModuleSuite.java:1115) at org.netbeans.junit.NbModuleSuite$S.turnClassPathModules(NbModuleSuite.java:1080) at org.netbeans.junit.NbModuleSuite$S.runInRuntimeContainer(NbModuleSuite.java:855) at org.netbeans.junit.NbModuleSuite$S.access$100(NbModuleSuite.java:660) I found that the method org.netbeans.junit.NbModuleSuite$S.rewrite doesn't consider an maven dependency with <classifier> set. I have fixed with a simple patch for now. # This patch file was generated by NetBeans IDE # It uses platform neutral UTF-8 encoding and \n newlines. --- Base (BASE) +++ Locally Modified (Based On LOCAL) @@ -1103,10 +1103,10 @@ StringBuilder classPathHeader = new StringBuilder(); for (String artifact : mavenCP) { String[] grpArtVers = artifact.split(":"); - String suffix = File.separatorChar + grpArtVers[0].replace('.', File.separatorChar) + File.separatorChar + grpArtVers[1] + File.separatorChar + grpArtVers[2] + File.separatorChar + grpArtVers[1] + '-' + grpArtVers[2] + ".jar"; + String partOfPath = File.separatorChar + grpArtVers[0].replace('.', File.separatorChar) + File.separatorChar + grpArtVers[1] + File.separatorChar + grpArtVers[2] + File.separatorChar + grpArtVers[1] + '-' + grpArtVers[2]; File dep = null; for (String classpathEntry : classpathEntries) { - if (classpathEntry.endsWith(suffix)) { + if (classpathEntry.endsWith(".jar") && classpathEntry.contains(partOfPath)) { dep = new File(classpathEntry); break; }
Created attachment 130829 [details] working patch
*** Bug 223086 has been marked as a duplicate of this bug. ***
This is probably the best that can be done for existing versions like RELEASE72 since org/netbeans/modules/org-netbeans-modules-maven-embedder/RELEASE72/org-netbeans-modules-maven-embedder-RELEASE72.jar#META-INF/MANIFEST.MF#Maven-Class-Path lists just sisu:sisu-guice:3.1.0 rather than sisu:sisu-guice:3.1.0:no_aop as it probably should (compare org-netbeans-modules-maven-embedder-RELEASE72.pom). Patch is a little sloppy since it could in principle match some other artifact paths that are not actually related, but I think it is unlikely—at least I cannot come up with a plausible example. Patch does not apply against trunk, since 6ec0a46585bd already fixed the issue for artifacts built with the 3.8+ plugin (MNBMODULE-178). Not sure if we need to work around the issue for older artifacts, but RELEASE73-BETA2 still does not seem to contain the fix, meaning RE needs to be using a more up-to-date version of what is now nb-repository-plugin. (Reminds me that nb-repository-plugin should somehow mention in the POM it generates what version of itself did the generation, since that is very helpful information when debugging this kind of issue!)
To accept your patch, I need you to sign OCA: http://www.oracle.com/technetwork/community/oca-486395.html
OCA has been signed and sent to oracle-ca_us@oracle.com
Working on the received OCA. Please stay tuned guys.
RELEASE73 still broken.
pgebauer: can you paste what command have you used to generate the RELEASE73 content? thank you.
Patch applied as http://hg.netbeans.org/ergonomics/rev/a526e21269bf Thanks for contributing to NetBeans.
(In reply to comment #8) > pgebauer: can you paste what command have you used to generate the RELEASE73 > content? thank you. /space/apache-maven-3.0.2/bin/mvn -DdeployUrl=....../space/builds/netbeans/7.3/maven2.73_alone -DforcedVersion=RELEASE73 -DnetbeansInstallDirectory=nbrepo/netbeans -DnetbeansJavadocDirectory=nbrepo/javadoc -DnetbeansNbmDirectory=nbrepo/nbms -DnetbeansSourcesDirectory=nbrepo/source-zips -DnexusIndexDirectory=nbrepo/nexus/ -DskipInstall=true org.codehaus.mojo:nbm-maven-plugin:3.8.1:populate-repository
(In reply to comment #10) > (In reply to comment #8) > > pgebauer: can you paste what command have you used to generate the RELEASE73 > > content? thank you. > > /space/apache-maven-3.0.2/bin/mvn > -DdeployUrl=....../space/builds/netbeans/7.3/maven2.73_alone > -DforcedVersion=RELEASE73 -DnetbeansInstallDirectory=nbrepo/netbeans > -DnetbeansJavadocDirectory=nbrepo/javadoc -DnetbeansNbmDirectory=nbrepo/nbms > -DnetbeansSourcesDirectory=nbrepo/source-zips > -DnexusIndexDirectory=nbrepo/nexus/ -DskipInstall=true > org.codehaus.mojo:nbm-maven-plugin:3.8.1:populate-repository that's out of date (I believe I've send an email about it when we had some problems with beta artifacts' index based recognition) we need additional -DrepositoryUrl=<URL> where URL is typically the central repository (http://repo1.maven.org/maven2/) and the goals are: org.codehaus.mojo:nb-repository-plugin:1.0:download org.codehaus.mojo:nb-repository-plugin:1.0:populate that makes sure we download the latest index using the maven indexer itself and process it before querying otherwise we get some false negatives when looking for GAV.
(In reply to comment #11) > that's out of date (I believe I've send an email about it when we had some > problems with beta artifacts' index based recognition) I'm sorry. It seems that I have missed it. I have thought that your communication is related only to your patch in the nexus plugin but I was wrong. I can see your new nbm-maven-plugin version 3.9 in codehouse repo. Is it the correct one? > we need additional -DrepositoryUrl=<URL> where URL is typically the central > repository (http://repo1.maven.org/maven2/) > > and the goals are: > org.codehaus.mojo:nb-repository-plugin:1.0:download > org.codehaus.mojo:nb-repository-plugin:1.0:populate So there have to be two separate calls of org.codehaus.mojo:nbm-maven-plugin? mvn -DforcedVersion=RELEASE73 -DrepositoryUrl=<URL> -Dnet......ipInstall=true org.codehaus.mojo:nbm-maven-plugin:3.9:download-repository mvn -DforcedVersion=RELEASE73 -DrepositoryUrl=<URL> -Dnet......ipInstall=true org.codehaus.mojo:nbm-maven-plugin:3.9:populate-repository Could be both goals in a one call? > that makes sure we download the latest index using the maven indexer itself and > process it before querying otherwise we get some false negatives when looking > for GAV. Just for the info: I have downloaded the latest index via your proprietary download application before the 73 maven repository was created. The index is only available internally. I can send you a link, if needed.
(In reply to comment #12) > (In reply to comment #11) > > > that's out of date (I believe I've send an email about it when we had some > > problems with beta artifacts' index based recognition) > > I'm sorry. It seems that I have missed it. I have thought that your > communication is related only to your patch in the nexus plugin but I was > wrong. I can see your new nbm-maven-plugin version 3.9 in codehouse repo. Is it > the correct one? > No. See below. > > we need additional -DrepositoryUrl=<URL> where URL is typically the central > > repository (http://repo1.maven.org/maven2/) > > > > and the goals are: > > org.codehaus.mojo:nb-repository-plugin:1.0:download > > org.codehaus.mojo:nb-repository-plugin:1.0:populate > > So there have to be two separate calls of org.codehaus.mojo:nbm-maven-plugin? > > mvn -DforcedVersion=RELEASE73 -DrepositoryUrl=<URL> -Dnet......ipInstall=true > org.codehaus.mojo:nbm-maven-plugin:3.9:download-repository > mvn -DforcedVersion=RELEASE73 -DrepositoryUrl=<URL> -Dnet......ipInstall=true > org.codehaus.mojo:nbm-maven-plugin:3.9:populate-repository Please note in my text above that the plugin is now org.codehaus.mojo:nb-repository-plugin:1.0 not org.codehaus.mojo:nbm-maven-plugin:3.9. It's been separated out because of extra dependencies on maven indexer that pulls way too many transtitive deps that are not needed by most users and it requires maven 3.0.4 that is also unwanted. You can execute both goals within the same command mvn <params> org.codehaus.mojo:nb-repository-plugin:1.0:download org.codehaus.mojo:nb-repository-plugin:1.0:populate
The latest daily snapshot has been generated via org.codehaus.mojo:nb-repository-plugin:1.0. Could you please check if everything is OK? http://bits.netbeans.org/trunk/maven-snapshot/
(In reply to comment #14) > The latest daily snapshot has been generated via > org.codehaus.mojo:nb-repository-plugin:1.0. > > Could you please check if everything is OK? > http://bits.netbeans.org/trunk/maven-snapshot/ unfortunately not, please see below. (In reply to comment #3) > > Patch does not apply against trunk, since 6ec0a46585bd already fixed the issue > for artifacts built with the 3.8+ plugin (MNBMODULE-178). Not sure if we need > to work around the issue for older artifacts, but RELEASE73-BETA2 still does > not seem to contain the fix, meaning RE needs to be using a more up-to-date > version of what is now nb-repository-plugin. > apparently the change mentioned in this comment only applies to modules *built* with maven, not the nb.org ones with *generated* metadata. I've released and tested new version of nb-repository plugin - version 1.0.1 which fixes the issue for generated content. I've manually verified by checking the maven embedder modules' manifest file in the generated repository and it's Maven-Class-Path attribute had the classifier added. new coordinates: org.codehaus.mojo:nb-repository-plugin:1.0.1 changelog: http://fisheye.codehaus.org/changelog/mojo/?cs=17975 The new version should be in central in a matter of hours or days.
The latest daily snapshot has been generated via org.codehaus.mojo:nb-repository-plugin:1.0.1 Could you please check it? http://bits.netbeans.org/trunk/maven-snapshot/
I performed just manual verification, org.sonatype.sisu:sisu-guice:3.1.0:no_aop is present in the module jar's manifest. Appears correct tome (In reply to comment #16) > The latest daily snapshot has been generated via > org.codehaus.mojo:nb-repository-plugin:1.0.1 > > Could you please check it? > http://bits.netbeans.org/trunk/maven-snapshot/
Integrated into 'main-golden', will be available in build *201303142300* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main-golden/rev/a526e21269bf User: Christian Lovsund <chrislovsund@netbeans.org> Log: #225522: consider maven dependency with <classifier>
Should the Target Milestone be 7.4 rather than Dev?
Does not seem to be fixed, or perhaps all the changes (to NB sources, NBM plugin, NB Maven repo) did not get coördinated. https://github.com/stapler/netbeans-stapler-plugin/blob/4bcd2229b2cc848d34b38909fba5fb35ff81654d/application/src/test/java/org/kohsuke/stapler/netbeans/plugin/ApplicationTest.java (in that version) shows a test defined for an app using RELEASE74 (which I presume contains the intended fix). Yet it fails with java.io.IOException: no match for org.apache.lucene:lucene-core:3.6.2 found in … at org.netbeans.junit.NbModuleSuite$S.rewrite(NbModuleSuite.java:1130) at org.netbeans.junit.NbModuleSuite$S.turnClassPathModules(NbModuleSuite.java:1095) at org.netbeans.junit.NbModuleSuite$S.runInRuntimeContainer(NbModuleSuite.java:867) at org.netbeans.junit.NbModuleSuite$S.access$100(NbModuleSuite.java:667) which seems to be the same error. Source ref: http://hg.netbeans.org/releases/file/release74/nbjunit/src/org/netbeans/junit/NbModuleSuite.java#l1130
Jesse, can you please repeat for me the steps to reproduce?
git clone https://github.com/stapler/netbeans-stapler-plugin/ && (cd netbeans-stapler-plugin && git checkout 4bcd2229b2cc848d34b38909fba5fb35ff81654d && mvn verify)
I've got the failure. Had to: $ mvn install -DskipTests $ cd application $ mvn test
Don't you have a mishmash in dependencies? lucene-core is used in version 3.5.0. The rest of the lucene libraries in version 3.6.2. I tried to declare a direct dependency on 3.6.2, but then somebody still requires 3.5.0. Constructing Maven dependency graph takes ages. Anyway the original error was about snapshot dependencies. This one is different and imho should be fixed in the project setup...
The dependency on lucene-3.5.0 comes from .m2/repository/org/netbeans/api/org-netbeans-libs-lucene/RELEASE74/org-netbeans-libs-lucene-RELEASE74.jar but as that code was written by you: 73ad61a46a4b - jglick 2.8.2011 turnClassPathModules in JEE6CRUDTest was creating config/Modules/org-netbeans-modules-web-client-javascript-debugger-an.xml [sic] due to manifest line wrapping. I hope you have some idea what to do about this. I don't even understand why we are processing transitive deps of every JAR individually and not use only those that are on Maven's classpath.
(In reply to Jaroslav Tulach from comment #24) > the original error was about snapshot dependencies No, rather about dependencies with classifiers. Not to say that this error is the same—may just be a different problem with a similar error message. Do not have time to investigate it now; when I am next working on this plugin suite I may recheck it.
I filed bug #271423 to follow up.