Uploaded image for project: 'Maven'
  1. Maven
  2. MNG-2480

Support for different types of version ranges in dependencies


    • Type: Improvement
    • Status: Closed
    • Priority: Major
    • Resolution: Incomplete
    • Affects Version/s: 2.0.4
    • Fix Version/s: None
    • Component/s: Dependencies
    • Labels:
    • Environment:



      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.





            • Assignee:
              pmonks Peter Monks
            • Votes:
              1 Vote for this issue
              2 Start watching this issue


              • Created: