Upgrade AspectJ and fold mockito-inline into mockito-core for Java 25

[jkschneider]

Two ways UpgradeToJava25 leaves a previously-building project unable to build. Both are in UpgradePluginsForJava25, inline alongside the existing plugin bumps, so no new recipe names are introduced.

mockito-inline is bumped to a version that was never published

Java 25 needs the Mockito java agent wired into surefire, so the migration raises Mockito. Where a project keeps a single shared ${mockito.version} property that also feeds mockito-inline, the result does not resolve:

Could not resolve dependencies: org.mockito:mockito-inline:jar:5.17.0

org.mockito:mockito-inline was discontinued after 5.2.0 (2023-03-09) once inline mocking became the default in mockito-core. Any bump of a shared property past that breaks every module declaring it.

- org.openrewrite.java.dependencies.ChangeDependency:
    oldGroupId: org.mockito
    oldArtifactId: mockito-inline
    newArtifactId: mockito-core
- org.openrewrite.maven.RemoveDuplicateDependencies

Renaming rather than removing matters: a module whose only Mockito dependency is mockito-inline would otherwise lose Mockito entirely. RemoveDuplicateDependencies handles the case where the rename collides with an existing mockito-core. Both steps are ordered ahead of the version bump so they land in the same cycle.

This mirrors what org.openrewrite.java.testing.mockito.Mockito4to5Only does upstream, inlined rather than composed because that recipe also drags a full Mockito 1→5 source migration into what is otherwise a build-file change.

AspectJ cannot compile at Java 25

Failed to execute goal org.codehaus.mojo:aspectj-maven-plugin:1.11:compile
  A required class was missing: org/aspectj/bridge/IMessageHolder

Verified against real compilers on Zulu 25 rather than release notes. ajc from aspectjtools:

invocation	1.9.7 (bundled by both plugins)	1.9.25.1
-25	unrecognized single argument: "-25"	exit 0
-25 -source 25 -target 25	—	exit 0
-1.8 -source 25 -target 25	—	Compliance level '1.8' is incompatible with source level '25'

So the aspectjtools pin is mandatory, and so is rewriting complianceLevel where a project spells out 1.8.

The coordinate moves to dev.aspectj on capability grounds. org.codehaus.mojo declares @Parameter(defaultValue = "1.4") String complianceLevel and emits -<level> unconditionally, so every AspectJ module that does not spell out complianceLevel would hard-fail the moment a Java-25-capable compiler is on the plugin classpath. dev.aspectj declares it with no default and falls back to source/target, which UpgradeJavaVersion has already moved to 25.

• Worth stating plainly since it is easy to assume otherwise: org.codehaus.mojo:aspectj-maven-plugin is not abandoned — 1.16.0 shipped 2026-01-18. But its Java 25 support (issue Migrate to sequenced collections in Java 21 / JEP 431 #243 / PR Remove Runtime.runFinalizersOnExit() in upgrade to Java 11 #244) adds the string "25" to ACCEPTED_COMPLIANCE_LEVEL_VALUES and nothing else, with no test, while still bundling aspectjtools 1.9.7. The reporter's original error is exactly what 1.9.7 produces, so that fix landed in the wrong place. Neither plugin reaches Java 25 without an explicit aspectjtools override.

The coordinate change is a drop-in: same artifactId, same goalPrefix, same goals, same org.codehaus.mojo.aspectj.* implementation classes, and dev.aspectj is a strict parameter superset.

One deliberate limit: the complianceLevel rewrite targets the plugin-level <configuration> only, not <executions>/<execution>/<configuration>.

Tests

Three added to UpgradeToJava25Test: shared version property with mockito-inline, the dedupe path, and the old AspectJ coordinate with complianceLevel 1.8. Full suite: 318 classes, 1935 tests, 0 failures.

Found by compiling the output of UpgradeToJava25 across a set of open source repositories.