[#MECLIPSE-405] to-maven target should allow to strip qualifier when creating artifacts from osgi bundles - jira.codehaus.org

Maven 2.x Eclipse Plugin

to-maven target should allow to strip qualifier when creating artifacts from osgi bundles

Created: 18/Mar/08 05:51 PM Updated: 18/Mar/08 06:43 PM Resolved: 18/Mar/08 06:25 PM

Component/s:

None

Affects Version/s:

2.5

Fix Version/s:

2.5.1

Time Tracking:

Not Specified

File Attachments:	1. to-mavenStringQualifier.patch (1 kB)
Environment:	Windows xp, regarding maven-eclipse-plugin, java 1.5

Patch Submitted:

Yes

Description

« Hide

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

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

Show »

Sort Order:

[ Permalink | « Hide ]

Carlos Sanchez added a comment - 18/Mar/08 05:57 PM

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

[ Permalink | « Hide ]

Apaar Trivedi added a comment - 18/Mar/08 06:09 PM

When is Maven 2.0.9 being released? Are you saying in maven 2.0.9+ this range issue will include 3.3.0.x in [3.3.0-3.4.0)? That is a relief.

Another issue I would like to mention is that you suggested on the mailing list to use make-artifacts and I would like to note that the artifact id's it provides are incorrect, which is the reason for its deprecation. For instance, make-artifacts will make an artifact with
groupId: org.eclipse.core
and then call its artifact id org.eclipse.core.boot,
when it should just be 'boot'.

This is the reason why we have not used make-artifacts to solve this problem. Additionally, would it hurt to provide the stripQualifier as a parameter so that people who are not using the eclipse nightly builds can still take advantage of eclipse:to-maven while still using maven 2.0.8-?

[ Permalink | « Hide ]

Carlos Sanchez added a comment - 18/Mar/08 06:21 PM

> When is Maven 2.0.9 being released?
1-2 weeks

> Are you saying in maven 2.0.9+ this range issue will include 3.3.0.x in [3.3.0-3.4.0)? That is a relief.
no, it will allow you to use dependencyManagement for you to workaround it

> Another issue I would like to mention is that you suggested on the mailing list to use make-artifacts and I would like to note that the artifact id's it provides are
incorrect, which is the reason for its deprecation. For instance, make-artifacts will make an artifact with
> This is the reason why we have not used make-artifacts to solve this problem. Additionally, would it hurt to provide the stripQualifier as a parameter so that people who are not using the eclipse nightly builds can still take advantage of eclipse:to-maven while still using maven 2.0.8-?

got it, parameters should be configurable in to-maven, but the defaults wont change, although I encourage you to use the qualifier or you wont know what build of eg 3.3.0 you are actually using

[ Permalink | « Hide ]

Carlos Sanchez added a comment - 18/Mar/08 06:25 PM

Fixed, thanks

although i stongly suggest you to use the qualifier

[ Permalink | « Hide ]

Apaar Trivedi added a comment - 18/Mar/08 06:29 PM - edited

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.

[ Permalink | « Hide ]

Carlos Sanchez added a comment - 18/Mar/08 06:43 PM

i know that issue and right now the only think you can do to work around it is explicitly set the versions in dependencymanagement (do it in the parent pom and it's a one time thing, see http://code.google.com/p/q4e/source/browse/branches/mavenbuild/pom.xml ). Stripping the qualifiers is a dirty hack.

you can get a RC of 2.0.9 at
http://people.apache.org/~brianf/staging-repository/org/apache/maven/apache-maven/2.0.9/