[
http://jira.codehaus.org/browse/MNG-3092?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_120773
]
David Hoffer commented on MNG-3092:
-----------------------------------
Can we decide what we are going to do regarding this bug? This issue has been
going on for a long time and some resolution is needed now.
In the past, we have made manual patches of maven to fix this bug. However now
I have found that I need to upgrade to 2.0.8 and I cannot because of this issue
(there may also be other places in maven where this needs to be applied as
well). I.e. since the release plug-in did not use maven's core to handle
version ranges we had to patch it as well, once this is fixed I would assume it
should use the core instead of duplicating logic.
I have found that release-plugin 2.0-beta-6 & 2.0-beta-7 are broken with
respect to 2.0.8 if using version ranges, refer to MNG-3351.
The current situation at our company is dire; we have spent the last 2 years
implementing an enterprise CI build system using maven. Now we find ourselves
in a situation were builds do not work anymore and I can find NO workaround.
That is, I have deploys that now fail because I (assume) am tripping over
transitive dependency bugs that have been fixed but I cannot use because I
cannot get to 2.0.8. I cannot go to 2.0.8 because with it most releases fail
(again see MNG-3351).
As far as I can tell, all of the failures are caused by usage of version
ranges; hence the need for this bug to be fixed.
It seems the main proponent of retaining the current behavior of version
ranges, gets around this issue because he does not use snapshots (does not
deploy snapshots). He simply replaces snapshot builds with releases and then
manually tags the releases with metadata to indicate the good vs. bad releases.
I am not convinced that this is the best way to go for an enterprise CI build
system. I feel the normal maven usage of snapshots and releases is too great
to give up.
I am at a point now that I need to know if this will be fixed or not, if yes
you will make us very happy, as we can continue with Maven. However if it
cannot be fixed I am forced into either not using version ranges or not using
Maven. We are an international company with well over 100 engineers, it would
be great to be able to use maven globally but because of this issue we are
forced to rethink our maven usage.
First, let me be clear why we are using version ranges. For internally
developed components & applications we make a contract with component
developers/consumers that we will not (knowingly) break an existing API unless
the major version changes, because of this contract we want
developers/consumers to always use the latest version of a released component.
Not only does always using the latest released version force usage of that
component so we can find problems, apply fixes, etc it also is our dependency
version management system. We don't need to ever say what version we want to
release with because we always want that which version range is supposed to
give us, i.e. the latest released version. (Note we always state the range of
versions we will accept, i.e. [1.23, 2.0).
Is there a way I can get this behavior without version ranges? I would be
happy to use a different syntax if available.
Now my first option (if this cannot be fixed asap) is to not use version
ranges. How can I get this behavior without them? I am not familiar with the
other mechanisms maven may have for dependency management. Is there some other
technique I can use? If I were to fix all versions could I write some plug-in
that would/could dynamically look for latest released versions and then rewrite
the pom to use what it finds?
Lastly, I hate to say it but we could move to something other than maven. I
understand there are maven like systems, i.e. buildr, that attempt at least to
not have these problems. How many other large companies find they can use
maven across the entire enterprise? I note there are 14 votes to fix this
issue, how are the other 13 working around this bug? I suspect that most using
maven are not using it internally to create libraries of reusable components
that are consumed by others within the same organization. If there are, I
would love to hear how they resolve this issue.
Regards,
Dave Hoffer
X-Rite, Inc.
> Version ranges with non-snapshot bounds can contain snapshot versions
> ---------------------------------------------------------------------
>
> Key: MNG-3092
> URL: http://jira.codehaus.org/browse/MNG-3092
> Project: Maven 2
> Issue Type: Bug
> Components: Dependencies
> Reporter: Mark Hobson
> Assignee: Mark Hobson
> Fix For: 2.0.x
>
> Attachments: MNG-3092.patch
>
>
> Contrary to the 2.0 design docs:
> "Resolution of dependency ranges should not resolve to a snapshot
> (development version) unless it is included as an explicit boundary."
> -- from
> http://docs.codehaus.org/display/MAVEN/Dependency+Mediation+and+Conflict+Resolution#DependencyMediationandConflictResolution-Incorporating%7B%7BSNAPSHOT%7D%7Dversionsintothespecification
> The following is equates to true:
> VersionRange.createFromVersionSpec( "[1.0,1.1]" ).containsVersion( new
> DefaultArtifactVersion( "1.1-SNAPSHOT" ) )
> The attached patch only allows snapshot versions to be contained in a range
> if they are equal to one of the boundaries. Note that this is a strict
> equality, so [1.0,1.2-SNAPSHOT] will not contain 1.1-SNAPSHOT.
--
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
