Support for different types of version ranges in dependencies
-------------------------------------------------------------
Key: MNG-2480
URL: http://jira.codehaus.org/browse/MNG-2480
Project: Maven 2
Issue Type: Improvement
Components: Dependencies
Affects Versions: 2.0.4
Environment: n/a
Reporter: Peter Monks
G'day,
It would be ideal if Maven supported different types of dependency version
ranges, to allow for more flexible dependency version resolution. For example,
if I was the provider of an open source library I might like to be able to
state that my code is dependent on some other library, and in the dependency
version section be able to say that it's been tested with one or two specific
versions (say [1.1,1.2]), but should theoretically work over a range of
versions (say [1.1,2.0) ). In this example the two version ranges might be
called the "soft" range and the "hard" range (or "certified" and "uncertified"
or whatever - the idea is what's important, not the terminology).
Currently many of the poms for open source libraries in the public Maven
repositories specify precise version numbers which invariably causes version
mismatches (which then tickles bug MNG-2123, but that's another story...). I
suspect that one of the reasons that open source teams do this is because
they've only tested their code against one version of each library they're
dependent upon, so it's understandable that they don't want to put a wider
range of version numbers in their poms. But this increases the changes of a
version number mismatch which forces the ultimate consumer of the library (and
its dependencies) to manually fiddle with poms until the various version number
ranges overlap.
If it were possible to specify "hard" vs "soft" version number ranges in the
poms directly, then open source providers may have more incentive to be more
permissive in their version number ranges, while still making it clear which
versions of their dependencies they've actually tested against.
Cheers,
Peter
--
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
