Details
-
Type:
New Feature
-
Status:
Closed
-
Priority:
Major
-
Resolution: Fixed
-
Affects Version/s: 2.5
-
Fix Version/s: 2.5.1
-
Component/s: None
-
Labels:None
-
Environment:Windows xp, regarding maven-eclipse-plugin, java 1.5
-
Patch Submitted:Yes
-
Number of attachments :
Description
There is a problem with to-maven target which forces the user to append the OSGI qualifiers to the artifact versions, thus making it impossible for dependencies to resolve one another, due to the fact that the range specified is not met with a version with a qualifier.
For instance, after mvn eclipse:to-maven is run, the eclipse plugins are added into the repository. Many of them depend on each other, and their dependency is based on a range, for instance 3.3.0-3.4.0, but the dependency provided ends up getting the version 3.3.0.-I20070403, i.e it has some qualifier and so it does not match up, and therefore the dependencies do not resolve and it all does not work.
The solution involves allowing the 'stripQualifier' parameter to be exposed in the plugin, here is a note I sent to the dev list:
We need one thing parameterized on the EclipseToMavenMojo.java in the maven-eclipse-plugin which should be parameterized anyway. In the call to osgiVersionToMavenVersion, it only allows 'false' to be passed in for the 'strip qualifier' parameter.
While the make-artifacts (which extends to-maven) target allows you to strip the qualifier, this is not a parameter that can be used in the to-maven target. This is a problem because using 'to-maven' provides artifacts with the proper names and hierarchy, but the dependecies do not resolve due to the qualifiers on the versions. While make-artifacts provides dependecies that resolve but the naming convention of the groupId's and artifactId's is incorrect, so this is also unacceptable, not to mention make-artifacts is deprecated for this reason.
Just a parameter -DstripQualifer that gets passed in to the call to
osgiVersionToMavenVersion( String version, String forcedQualifier, boolean stripQualifier ) would be perfect.
I have included a patch which provides this parameter and uses it in the necessary call to the method, while leaving its default value as false, thus no functionality would change unless the parameter is used. Please consider this asap, as it is stopping some work of ours here and I have had to modify the source and install a fixed copy to my local repo to currently get around this.
Thank you
Attachments
Activity
Fixed, thanks
although i stongly suggest you to use the qualifier 
You fixed it while i was still writing this. Thanks!! 
>although I encourage you to use the qualifier or you wont know what build of eg 3.3.0 you are actually using
That is actually the problem. So when the qualifiers are appended to the versions, artifact foo version 3.3.0-SomeQualifier doesnt resolve when artifact bar says
<dependency>
<artifactId>foo<artifactId>
<version>[3.3.0,4.0.0)</version>
<groupId>some Group...</groupId>
<dependency>
it cannot resolve foo, the error message returned is 'Couldn't find a version in [3.3.0-SomeQualifier] to match range [3.3.0,4.0.0).' from artifact bar. Does this make sense? I was told by someone in #maven that this happens because of the way versions are compared. Thanks.
>although I encourage you to use the qualifier or you wont know what build of eg 3.3.0 you are actually using
That is actually the problem. So when the qualifiers are appended to the versions, artifact foo version 3.3.0-SomeQualifier doesnt resolve when artifact bar says
<dependency>
<artifactId>foo<artifactId>
<version>[3.3.0,4.0.0)</version>
<groupId>some Group...</groupId>
<dependency>
it cannot resolve foo, the error message returned is 'Couldn't find a version in [3.3.0-SomeQualifier] to match range [3.3.0,4.0.0).' from artifact bar. Does this make sense? I was told by someone in #maven that this happens because of the way versions are compared. Thanks.
the qualifier is an important part of the version, it's not the same 3.3.0.x than 3.3.0.y so if Eclipse releases both versions we are not the people to strip it
You can use dependencyManagement section to explicitly set the versions from Maven 2.0.9+
i've given a presentation at EclipseCON talking about this and other problems, will post them soon
http://www.jroller.com/carlossg/entry/letters_from_eclipsecon