[
http://jira.codehaus.org/browse/MECLIPSE-405?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_127847
]
partriv edited comment on MECLIPSE-405 at 3/18/08 6:32 PM:
-----------------------------------------------------------------
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.
was (Author: partriv):
>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.
> to-maven target should allow to strip qualifier when creating artifacts from
> osgi bundles
> -----------------------------------------------------------------------------------------
>
> Key: MECLIPSE-405
> URL: http://jira.codehaus.org/browse/MECLIPSE-405
> Project: Maven 2.x Eclipse Plugin
> Issue Type: New Feature
> Affects Versions: 2.5
> Environment: Windows xp, regarding maven-eclipse-plugin, java 1.5
> Reporter: Apaar Trivedi
> Assignee: Carlos Sanchez
> Fix For: 2.5.1
>
> Attachments: to-mavenStringQualifier.patch
>
>
> 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
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
