Maven: pin the repository in two mirror-sensitive failure tests

[Niloyyy]

What's changed?

Re-enables two of the six tests disabled on 2026-05-04 after the Artifactory switch, by making their assertions independent of whatever mirror is configured rather than by skipping them.

• AddDependencyTest.dontAddDuplicateIfUpdateModelOnPriorRecipeCycleFailed
• MavenDependencyFailuresTest.unresolvableMavenMetadata

Root cause

Both assert on a concrete repository URL, and a mirror rewrites it. Reproduced locally by pointing a wildcard <mirrorOf>*</mirrorOf> at repo1.maven.org (standing in for Artifactory) with the @Disabled removed:

-https://repo.maven.apache.org/maven2: HTTP 404)~~>--><dependency>
+https://repo1.maven.org/maven2/: HTTP 404)~~>--><dependency>

Expecting actual:  ["https://repo1.maven.org/maven2/"]
to contain exactly in any order:  ["https://repo.maven.apache.org/maven2"]

The mirror reaches them because Assertions.customizeExecutionContext (and MavenSettingsAutoLoadingExtension) load ~/.m2/settings.xml whenever the context has nothing configured. unresolvableMavenMetadata already pins its parser context, but left recipeExecutionContext a bare InMemoryExecutionContext, which is the one the metadata lookup uses.

Approach

• Both guards load settings only when nothing is configured, so pinning the repository opts out. That keeps the tests running in CI rather than skipping them there, which is why I went this way instead of the @DisabledIfEnvironmentVariable treatment Provide Artifactory credentials to CI #7566 applied to the emptyRepositories tests.

Worth noting Assertions.customizeExecutionContext ships in rewrite-maven main, not test — so this sensitivity affects downstream users whose ~/.m2/settings.xml has a mirror, not only this repo's CI.

What it costs

The pinned context no longer honours a user's mirror for these two tests, which is the point but does mean they exercise a slightly narrower path than a default-context test. Both are failure-path tests asserting an exact message, so there is nothing a mirror would usefully add.

Tests

AddDependencyTest + MavenDependencyFailuresTest, run both ways:

	no mirror	wildcard mirror
before (@Disabled removed, unpinned)	pass	fail (output above)
after (pinned)	pass	pass

Final state: 59 tests, 0 failures, 0 errors, 1 skipped — identical with and without a mirror. The 1 skip is unresolvableParent, left disabled (below).

The other four

Deliberately untouched. I could not reproduce failures for MavenDependencyFailuresTest.unresolvableParent, UpgradePluginVersionTest$PluginRepos.repoUnreachable, or UpgradePluginVersionTest$PluginRepos.noNewerVersion — but my stand-in mirror is not a faithful Artifactory: it does not proxy Red Hat GA or the Jenkins repo. The tell is that the currently-enabled UpgradePluginVersionTest$PluginRepos.update fails under my stand-in because Central has no 3.15.3.redhat-00002. All three of those tests depend on those same non-Central repositories, so "didn't reproduce here" is not evidence they'd pass against the real cache — someone who can run CI against Artifactory is better placed to settle them.

• The sixth, rewrite-gradle's UpgradeDependencyVersionTest.cannotDownloadMetaDataWhenNoRepositoriesAreDefined, has a different root cause and is handled separately in Gradle: disable the no-repositories metadata test only when a mirror is injected #8664.