[ 
http://jira.codehaus.org/browse/MECLIPSE-267?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_95483
 ] 

Matthew Beermann commented on MECLIPSE-267:
-------------------------------------------

I just wanted to chime in and point out that:

* Version ranges appear to be discouraged within Maven, in general - they're 
used almost nowhere within Maven itself.

* Although Maven and OSGi both appear to support version ranges, the 
resemblance is superficial. In particular, they make opposite assumptions about 
whether a qualified version is greater than or less than its unqualified 
counterpart. Which means that blindly reusing the OSGi range in Maven (as the 
plugin does today) is actually quite dangerous.

> Enhance make-artifacts to not create POMs that have version ranges
> ------------------------------------------------------------------
>
>                 Key: MECLIPSE-267
>                 URL: http://jira.codehaus.org/browse/MECLIPSE-267
>             Project: Maven 2.x Eclipse Plugin
>          Issue Type: Improvement
>          Components: PDE support
>    Affects Versions: 2.3
>            Reporter: Micah Whitacre
>
> Currently when using the make-artifacts goal to deploy Eclipse artifacts to a 
> remote repository the POMs are created in such a way the versions of the 
> dependencies have ranges similar to [3.3,4).  This information is pulled from 
> the Manifest.  I'd like a way to specify not to use those version ranges in 
> the POM but to instead have a soft dependency on a specific version.  The 
> situation that is occurring is that when I have deployed both Eclipse 3.2 and 
> 3.3 endstates to a remote repository, the 3.2 dependencies have ranges 
> specified which then pull in the 3.3 endstates.  This causes conflicts when I 
> want to only include 3.2 endstates.  If there was a way to 1. not use version 
> ranges in the POM and 2. instead have a soft dependency on a specific 
> version.  This would eliminate the need to specify each and every Eclipse 3.2 
> artifact for fear a transitive 3.3 dependency got pulled in.
> I have also seen this cause errors when a transitive dependency pulls in a 
> 3.3 endstate that has conflicting version ranges for an artifact I have a 
> dependency on.  Since the 3.3 endstates will have version ranges of [3.3,4) 
> but I might specify 3.2 dependencies, if I have a first class dependency on 
> 3.2 and a transitive dependency on the same artifact but the range is 
> [3.3,4),  I will not be able to build my project.

-- 
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

        

Reply via email to