https://maveniverse.eu/tags/version-range/Recent content in Version-Range on MaveniverseHugoenFri, 17 Apr 2026 14:30:01 +0200https://maveniverse.eu/blog/2026/04/17/taming-maven-version-ranges/Fri, 17 Apr 2026 10:07:53 +0100https://maveniverse.eu/blog/2026/04/17/taming-maven-version-ranges/<p>Maven ranges are very controversial topic. If you ask anyone, the response most often is &ldquo;do not use them&rdquo;. And while there are good reasons for that, there are also some use cases where they can be useful. So lets see how can Maven 3.10.x help with them.</p> <h2 id="problems">Problems</h2> <p>Biggest issue with ranges, is that when they are collected by resolver, following steps are applied:</p> <ul> <li>current POM processed dependency contains a version range, for example <code>[1.0,2.0)</code></li> <li>resolver collects all versions of the dependency, for example <code>1.0</code>, <code>1.1</code>, <code>1.2</code> etc up to <code>2.0</code> (including alphas, snapshots&hellip; if such artifacts are in scope, for example snapshot repository is used for resolution)</li> <li>dirty graph gets nodes created for each version and builds subtree for each (given dependencies may differ across versions)</li> <li>finally, conflict resolver &ldquo;choose&rdquo; the winner node (version) and eliminates the rest.</li> </ul> <p>From these, one can immediately notice several problems:</p>