Add a Maven 4 job to CI #1182

Problem

We have no signal on whether this plugin works under a Maven 4 runtime. CI builds with ./mvnw only (.mvn/wrapper/maven-wrapper.properties pins apache-maven 3.9.8), so every test and integration test runs on Maven 3.9.x. With Maven 4.0.0-rc-6 out, we will start getting user reports before we have any way to reproduce them.

Structurally we look fine

Worth stating up front, because the fix here is CI and not a rewrite:

• JSR-330 @Inject rather than Plexus @Component (AbstractRewriteMojo.java:59-66)
• Modern Aether / org.eclipse.aether.RepositorySystem throughout ArtifactResolver
• No maven-compat (dropped in chore: drop legacy, use resolver #560), no ArtifactRepository, no MavenProjectHelper, no PlexusContainer
• @Mojo annotations use only Maven 4-supported attributes

Per Apache's compatibility plan, Maven 3.9-era plugins run unchanged on Maven 4 provided they avoid Maven 2-era APIs. Staying on maven-plugin-api 3.9.x and maven-plugin-tools 3.15.x is the correct choice for now — the migration guide says the Maven 4 plugin API is experimental in 4.0.0 and should not be adopted yet. This issue is not asking for a plugin API upgrade.

Proposal

Add a Maven 4 job to .github/workflows/ci.yml — a matrix entry, or a separate non-blocking job initially so it doesn't gate merges while we shake it out.

Specific things a Maven 4 run would tell us

These are code-reading hypotheses, not observed failures. The point of the CI job is to find out which are real:

1. MXSerializer / plexus-utils — ConfigurableRewriteMojo.java:25,281 imports org.codehaus.plexus.util.xml.pull.MXSerializer. plexus-utils is only managed here (pinned 3.6.1 for GHSA-6fmv-xxpf-w3cw) and arrives transitively provided via maven-core. Maven 4 core no longer exports it, so this could be a NoClassDefFoundError. Reached only via the inline-checkstyle-rules path, so a plain build may not exercise it.

2. Xpp3Dom casts — MavenMojoProjectParser.java:309,385,422,1049 and ConfigurableRewriteMojo.java:249 do instanceof Xpp3Dom on Plugin.getConfiguration(). Maven 4 configuration is XmlNode-backed; plexus-xml 4.1.1 provides a compat Xpp3Dom, but if the types don't line up these instanceof checks fall through silently — source/target/encoding detection returns null and we produce a subtly wrong LST rather than failing. This is the one I would most want covered by an assertion, not just a green build.

3. ClassRealm — AbstractRewriteBaseRunMojo.java:309-322 casts the TCCL to ClassRealm and calls addURL. classworlds survives in Maven 4, but the RC-6 notes mention classrealm layout changes causing "foreign imports" errors for some plugins.

4. <prerequisites><maven>3.3.1</maven></prerequisites> is stale regardless and probably wants revisiting once we know what actually works.

Also worth knowing

Maven 4's TransitiveDependencyManager applies dependencyManagement at all transitive depths, which can change resolved versions relative to Maven 3. That is a rewrite-maven resolution question rather than a plugin question, but it means a Maven 4 CI job may surface dependency differences that are not plugin bugs.