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.

Bug 225522 - no match for org.sonatype.sisu:sisu-guice:3.1.0 found
Summary: no match for org.sonatype.sisu:sisu-guice:3.1.0 found
Status: RESOLVED FIXED
Alias: None
Product: platform
Classification: Unclassified
Component: NB JUnit (show other bugs)
Version: 7.2
Hardware: All All
: P3 normal with 1 vote (vote)
Assignee: Jaroslav Tulach
URL: https://jira.codehaus.org/browse/MNBM...
Keywords:
: 223086 (view as bug list)
Depends on:
Blocks:
 
Reported: 2013-01-30 11:28 UTC by chrislovsund
Modified: 2017-09-02 16:16 UTC (History)
4 users (show)

See Also:
Issue Type: DEFECT
Exception Reporter:


Attachments
working patch (1.57 KB, patch)
2013-01-30 11:33 UTC, chrislovsund
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description chrislovsund 2013-01-30 11:28:51 UTC
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;
                     }
Comment 1 chrislovsund 2013-01-30 11:33:04 UTC
Created attachment 130829 [details]
working patch
Comment 2 Jaroslav Tulach 2013-02-04 11:17:54 UTC
*** Bug 223086 has been marked as a duplicate of this bug. ***
Comment 3 Jesse Glick 2013-02-04 17:46:31 UTC
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!)
Comment 4 Jaroslav Tulach 2013-02-12 12:27:41 UTC
To accept your patch, I need you to sign OCA: http://www.oracle.com/technetwork/community/oca-486395.html
Comment 5 chrislovsund 2013-02-12 14:06:42 UTC
OCA has been signed and sent to oracle-ca_us@oracle.com
Comment 6 Jiri Kovalsky 2013-02-14 10:22:45 UTC
Working on the received OCA. Please stay tuned guys.
Comment 7 Jesse Glick 2013-02-26 05:50:54 UTC
RELEASE73 still broken.
Comment 8 Milos Kleint 2013-02-26 06:06:31 UTC
pgebauer: can you paste what command have you used to generate the  RELEASE73 content? thank you.
Comment 9 Jaroslav Tulach 2013-02-26 14:58:50 UTC
Patch applied as http://hg.netbeans.org/ergonomics/rev/a526e21269bf
Thanks for contributing to NetBeans.
Comment 10 pgebauer 2013-02-26 15:36:38 UTC
(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
Comment 11 Milos Kleint 2013-02-26 17:53:39 UTC
(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.
Comment 12 pgebauer 2013-02-27 14:04:36 UTC
(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.
Comment 13 Milos Kleint 2013-02-27 14:28:32 UTC
(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
Comment 14 pgebauer 2013-03-04 14:15:37 UTC
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/
Comment 15 Milos Kleint 2013-03-04 15:48:38 UTC
(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.
Comment 16 pgebauer 2013-03-05 08:40:16 UTC
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/
Comment 17 Milos Kleint 2013-03-05 09:27:42 UTC
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/
Comment 18 Quality Engineering 2013-03-15 01:46:57 UTC
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>
Comment 19 Jesse Glick 2013-10-17 14:08:11 UTC
Should the Target Milestone be 7.4 rather than Dev?
Comment 20 Jesse Glick 2013-10-17 15:12:33 UTC
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
Comment 21 Jaroslav Tulach 2013-12-18 16:40:54 UTC
Jesse, can you please repeat for me the steps to reproduce?
Comment 22 Jesse Glick 2013-12-18 17:36:11 UTC
git clone https://github.com/stapler/netbeans-stapler-plugin/ && (cd netbeans-stapler-plugin && git checkout 4bcd2229b2cc848d34b38909fba5fb35ff81654d && mvn verify)
Comment 23 Jaroslav Tulach 2013-12-19 09:29:33 UTC
I've got the failure. Had to:

$ mvn install -DskipTests
$ cd application
$ mvn test
Comment 24 Jaroslav Tulach 2013-12-19 09:43:55 UTC
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...
Comment 25 Jaroslav Tulach 2013-12-19 09:59:42 UTC
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.
Comment 26 Jesse Glick 2013-12-19 14:53:31 UTC
(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.
Comment 27 Jesse Glick 2017-09-02 16:16:59 UTC
I filed bug #271423 to follow up.