Details
-
New Feature
-
Status: Closed
-
Major
-
Resolution: Fixed
-
2.5
-
None
-
None
-
Windows xp, regarding maven-eclipse-plugin, java 1.5
-
Patch
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