Version Range Resolution Differences Between Local and CI Builds

Answer

To get the same resolved version from a Maven range in both a local IDE build and a clean CI build, follow these steps:

1. Verify that both environments use identical settings.xml (mirrors, repository URLs, and proxy configuration).
2. Set the snapshot update policy to never (or a fixed interval) in the <snapshots>
3. If the project must keep the version range, run mvn versions:resolve-ranges locally and commit the generated dependency-reduced-pom.xml (or lock the versions with versions-maven-plugin's update-properties goal) so that CI builds read the fixed versions.
4. Alternatively, replace the range with an explicit <version> in the <dependencyManagement>

These actions remove the influence of locally installed snapshots and ensure CI only sees the same released artifacts that the range would pick.

Likely explanation

Maven selects the highest version that satisfies the range at build time. A local IDE often has recently built snapshots installed in the local repository, so a range like [1.0,2.0) may resolve to a snapshot that CI cannot see because CI only queries remote release repositories. Differences in <updatePolicy> (e.g., always vs default) can also cause CI to fetch a newer snapshot than a cached local copy, leading to divergence.

Confirmed facts

• Maven’s range resolution is deterministic given the same set of available artifacts.
• Snapshot update policy controls how often Maven checks remote repositories for newer snapshots.
• Using a fixed version or a dependency‑reduced POM eliminates range‑based variability.
• Maven’s best practice recommends avoiding version ranges for production dependencies to ensure reproducible builds.

Missing diagnostic detail

Are you using the same settings.xml (including mirrors and repository URLs) in both the local IDE and the CI agent? If the answer is no, aligning the settings is the first required step before applying the fixes above.