Don't raise a shared version property to a version its siblings never published

[MBoegers]

UpgradeDependencyVersion writes the new version into a <properties> entry without checking that the version exists for the other artifacts resolving through that property. Every sibling reading the property is left pointing at a version that was never published, and the POM stops resolving.

The failure surfaces as Unable to download POM: com.fasterxml.jackson.core:jackson-core:2.21, and the same for every other artifact sharing that ${jackson.version}. UpgradeJackson_2_3_Dependencies pins jackson-annotations to 2.21, which is a real release of jackson-annotations and of nothing else — it moved to bare minor versions at 2.20 while the rest of Jackson 2.x kept three parts. The recipe isn't at fault; any exact version that only one consumer of a shared property publishes does this.

<properties>
    <jackson.version>2.19.0</jackson.version>
</properties>
<dependencies>
    <dependency>… jackson-annotations … <version>${jackson.version}</version></dependency>
    <dependency>… jackson-core        … <version>${jackson.version}</version></dependency>
</dependencies>

Before this change the property becomes 2.21 and jackson-core is unresolvable.

Behaviour

When the new version is not published for every consumer of the property, the targeted dependency is decoupled instead: an explicit <version> on the dependency or on its dependencyManagement entry, with the property untouched. Properties with a single consumer behave exactly as before. This is already what rewrite-gradle does for a shared version variable, so the two stay aligned on identical input.

Three things beyond the report

A glob breaks the artifact it was asked to upgrade. With com.fasterxml.jackson.core:*, the competing property writes race and the last one wins, so jackson-annotations ends up broken alongside jackson-core. Checking the new version against every consumer rather than only the untargeted ones subsumes the separate agreement phase the Gradle recipe spells out, and both artifacts now decouple to versions that exist.

A module of the build is a sibling too. Modules were exempt from the existence check, which is tempting because a module publishes nothing to probe and would 404 every time. But exempting it raises the property out from under the module and breaks it exactly as it breaks an external artifact — the same failure with an in-repo sibling. A module is now checked against the version it already carries, which needs no repository.

The accumulator could not survive the runtime it runs in. Every source file writes to it, and a runtime that visits source files in parallel writes from several threads at once. The version-existence verdicts are the worst of them: written during the edit phase with a value that comes from a download, so the window is as wide as the network is slow. Backed by HashMap and HashSet those writes drop entries — 880 of 4000 in the accompanying test — and a dropped entry in the consumer index is a missing sibling, which is how a property gets raised to a version that sibling never published. The corruption reinstates the bug the check exists to prevent, only under the parallel runner where no test was looking.

The probe is also lifted out of computeIfAbsent, whose contract asks for a short mapping function; one that blocks on a download holds its bin against every other writer.

Tests

• UpgradeDependencyVersionSharedPropertyTest pins both directions per POM shape — the decouple, and the property bump that has to survive it. The pairing is the point. The Gradle equivalent (UpgradeDependencyVersion (Gradle): respect shared version variables #7491) shipped with three tests, all asserting that a shared variable is not bumped when that would break a sibling and none asserting that it still is when it wouldn't, so the gate it introduced was free to be far stricter than intended and had to be relaxed ten days later in UpgradeDependencyVersion for Gradle preserves shared version variable references when upgrading dependencies #7694. Nesting the two directions together makes shipping half a gate visible at a glance.

Partitioning the input turned up three more classes nothing reached: a BOM import sharing a property with an artifact on a different version scheme, a managed entry reached from a dependency that declares no version of its own, and a version that merely contains a placeholder rather than being one. The first two were already correct and are now held there; the third does nothing, and the boundary is pinned because the obvious repair reaches for a property that does not exist and would write straight through the gate.

Full :rewrite-maven:test is green — 1541 tests.

Two deliberate choices worth a reviewer's attention

A metadata download that fails is answered as though the version were present. Failing closed would decouple every shared property on a degraded run, which is the far more expensive mistake. The cost is that a network-degraded run quietly reverts to the old behaviour, so the probe now goes through the MavenMetadataFailures table the recipe already declares — it was the one download bypassing it — and a run can be asked afterwards whether the check had anything to go on. Narrowing this further, by treating a clean 404 from every repository as evidence while a transport error stays open, is the obvious next step and is deliberately not here: it is the piece with real over-correction risk and nothing to test it against yet.

• The module gate has no safe-direction twin, on purpose. A module's own version does not coincide with an arbitrary new version of an external artifact, so there is no branch that legitimately lets a module consumer through. The absence is not the omission UpgradeDependencyVersion (Gradle): respect shared version variables #7491 shipped, and it is written into the test class so it doesn't read as one.

Not in here

propertyKey falls back to a null path when no POM in the sources declares the property, so every property inherited from a remote parent lands on one key. Two module trees inheriting different remote parents that declare the same property name would merge their consumer sets, which over-decouples. Narrow and cosmetic, but worth keying on the declaring POM's GAV eventually.

Credit

• Built on tim/taipei-v2 from Don't bump a shared version property to a version its siblings lack #8460. The first two commits are Tim's, unchanged.

• Fixes UpgradeDependencyVersion bumps a shared version property to a version its siblings never published #8656