Type: New Feature
Resolution: Won't Fix
Affects Version/s: None
Fix Version/s: None
(This is a subset of the larger dependency management issues discussed in
An useful subset of the larger dependency management problem with version ranges is the idea of pinning a dependency down to a specific version. The syntax would look like this:
group: 'net.twasink', name: 'myartifact', version: '[1.0]'
This syntax has the advantage of being compatible with both Ivy and Maven.
Using pinned versions are a very convenient way of dealing with transitive dependencies that bring in newer undesired versions. This can be done manually - using the 'failOnConflict' approach from
GRADLE-1899 to detect the conflicts, and then setting up exclusion rules - but that can be a time consuming process, especially for common 3rd-party libraries (e.g. differing, but compatible, versions of commons-lang). It also produces a lot of verbosity. By using this subset of version range matchers, a very common use case ('use exactly this version of that library') is solved. I have a vested interest in this as I have a large set of Maven-based projects that I would love to convert to Gradle, but which use pinned versions for exactly this task.
(Naturally, if the same dependency has multiple pinned versions in the tree, then a conflict would occur)
I've developed a bunch of Cucumber tests to drive Gradle and compare its behaviour to Maven. These tests are available at https://github.com/twasink/GradleDependencyTests - see https://github.com/twasink/GradleDependencyTests/blob/master/features/pinned_dependencies.feature in particular.
The result of the tests (against current Gradle head) is at http://twasink.net/files/gradle_dependency_result_2011_12_09.html