10aday › tools
Type a Maven dependency version such as [1.0,2.0), (,1.5] or [1.2], and the versions published for that library.
You see which versions match, in plain words, and which one Maven will pick. The page runs a JavaScript copy of the code Maven 3.9 itself uses
(Maven Resolver 1.9.24), checked against the real Java classes and against real mvn runs.
[1.0,2.0) accepts 2.0 pre-releasesMaven sorts 2.0-alpha-1 < 2.0-beta1 < 2.0-rc1 < 2.0-SNAPSHOT < 2.0. All of them are below 2.0, so an upper bound of 2.0) lets them in.
We ran Maven 3.9.11 on a test repository holding 1.0, 1.5, 1.9.9, 2.0-alpha-1, 2.0-beta1, 2.0-rc1, 2.0 and 2.0.1:
| In pom.xml | Maven picked | Why |
|---|---|---|
| [1.0,2.0) | 2.0-rc1 | 2.0-rc1 is lower than 2.0, so it is inside the range, and it is the highest one. |
| [1.0,2.0-SNAPSHOT) | 2.0-rc1 | rc1 is lower than SNAPSHOT for Maven, so this does not help. |
| [1.0,2-alpha) | 1.9.9 | Works for usual names (alpha, beta, milestone, rc, SNAPSHOT). |
| [1.0,2.0.min) | 1.9.9 | Safest: 2.0.min means “the smallest version of the 2.0 line”. |
| [1.0,2.0] | 2.0 | Upper bound included. |
| [1.*] | build error | Maven 3.9 refuses * in a dependency version. |
| Write | Means | Matches (from 1.0, 1.1, 1.5, 2.0-rc1, 2.0, 2.1) |
|---|
The “Matches” column is computed in your browser by the same engine as the checker above.
Maven cuts a version into parts at ., -, _ and at each switch between digits and letters. Numbers compare as numbers (so 1.10 > 1.9).
Known words have a fixed rank: alpha = a < beta = b < milestone = m < rc = cr < snapshot < release (ga, final, release or nothing) < sp.
Any other word (jre, android, foo) ranks above all of them and they compare alphabetically, case ignored. Trailing zeros do not count.
| Version | Parts as Maven reads them |
|---|
Related: for npm, Cargo, Composer, pip and RubyGems constraints such as ^1.2 or ~> 2.1, use the Version Constraint Checker.
To sort a list of versions the way those five sort them, use the Version sorter. For .NET, the same bracket syntax behaves differently: see the NuGet version range checker (NuGet takes the lowest match). Gradle reads the same brackets but skips 2.0-rc1 in [1.0,2.0): see the Gradle dynamic version checker. For pre-releases in other ecosystems, see what each package manager installs when a beta is out.
Any version from 1.0 included up to 2.0 excluded. Square brackets include the bound, round brackets exclude it. Maven then takes the highest version in the repository that falls in the range.
For Maven, 2.0-alpha-1, 2.0-beta1, 2.0-rc1 and 2.0-SNAPSHOT are all lower than 2.0, so they are inside [1.0,2.0). Tested with Maven 3.9.11: [1.0,2.0) resolved to 2.0-rc1. To stop before any 2.0 pre-release, write [1.0,2.0.min): it resolved to 1.9.9.
1.0 is a soft requirement: Maven uses 1.0 unless another path in the dependency tree is nearer and asks for something else. [1.0] is a hard requirement: Maven asks the repository for exactly the text 1.0, without reading the list of published versions. Tested with Maven 3.9.11: [3.0] failed although 3.0.RELEASE, an equal version, was published.
No. Maven Resolver understands [1.*] as [1.min,1.max], but Maven 3.9 refuses a dependency version that contains * when it reads the POM. Use [1,2.min) instead.
Combine ranges with commas: (,1.1),(1.1,) accepts everything except 1.1. The result is the union of all the ranges.
Yes. Trailing zeros and the qualifiers final, ga and release are ignored, so 1.0 = 1.0.0 = 1.0-ga = 1.0.Final. But 1.0-sp is higher than 1.0, and 1.0-foo is higher than 1.0 and lower than 1.0.1.
For Go programs: the same rules as a library, github.com/Lawatch/10aday/verrange/maven (open source, no dependencies, tested against Maven Resolver 1.9.24 and real Maven builds).
From a terminal, with Go installed: go run github.com/Lawatch/10aday/verrange/cmd/verrange@latest maven "[1.0,2.0)" 1.0 1.5 2.0 prints yes or no for each version, then the one the tool would pick (command docs).
GenericVersionScheme (version syntax, min and max, [M.N.*]): maven.apache.org/resolver