Proposal to EOL Maven 3.9.x line along with Resolver 1.x line, make Maven 3.10.x the new "stable" lineage.

  • Use of Resolver 2.x (at the same time EOL Resolver 1.x lineage); Resolver 2.x is still Java 8 baseline, while some modules are not (ie. JDK transport is MR-JAR, that is no-op on Java 8 but "activates" on Java 11+).

3.10.0 https://github.com/apache/maven/milestone/126

Proposed changes

Migrate fully to JSR 330

We need to fully move off Plexus (as much as possible). No component should use Plexus, given Java 26 is coming (and Plexus is capable of field injection only, fx see https://github.com/apache/maven/pull/11711).

Unclear about replacement for configuration of components which previously were leveraging Plexus Component Configurator, the alternative outlined in https://eclipse.dev/sisu/org.eclipse.sisu.plexus/conversion-to-jsr330.html#a.40Configuration doesn't seem to be easily overridable and doesn't seem to support type coercion.

What happens to the Core Classloader with regards to Wagon/Plexus: https://github.com/apache/maven/blob/maven-3.9.x/maven-core/src/main/resources/META-INF/maven/extension.xml?

Wagon and Resolver?

Currently Wagon is still relying on Plexus, and Resolver provides a Transporter for Wagon which configures Wagon via Plexus Component Configurator in https://github.com/apache/maven-resolver/blob/8457466c60bad78a04e1f3e5615545eea4c89a4d/maven-resolver-transport-wagon/src/main/java/org/eclipse/aether/internal/transport/wagon/PlexusWagonConfigurator.java#L77.

Backport user- and system-wide extensions support

Maven 3 historically supports only .mvn/extensions.xml . Today, extensions like Mimir prove very useful, and should be real "user wide" as they are totally orthogonal to builds. Maven 3.10.x should support user-wide ${user.hom}/.m2/extensions.xml and system wide ${maven.home}/conf/extensions.xml in same was as Maven 4 does.

Fix settings.xml interpolation

Right now in all of Maven 3.x line settings.xml interpolation seems totally borked.

Promote use of session.topDirectory  and session.rootDirectory  to real properties

These two properties were "mild backported" to 3.9.x, making them available in CLI parameters interpolation only. They are useful, we should make them "real" properties usable in POM and everywhere.

To not have "tricks" like these https://github.com/kordamp/pomchecker/blob/ba1d89693d27d1b36bcb29cb1bb123015187f63b/.mvn/maven.config

Activate Reproducible Builds by default

https://github.com/apache/maven/pull/12032

What does not change

  • Model and all around it, we still keep the "good old" Xpp3Dom stuff (we cannot backport Woodstox changes, nor should backport any of the newer models)
  • The new CLI tools like mvnup  or mvnenc  etc are not being backported.
  • The new security (Maven 3.x remains with plexus-sec-dispatcher 2.x) is not being backported.


Rejected proposals

Ingest Nisse (or support os-detector like properties)

Extend Maven built in property support, either by ingesting Nisse, or some alternative. Today, many tools rely on OS properties (originally injected by os-detector) and there are many libraries that are not resolvable without these. OTOH, many tools like JBang and pomchecker already create Resolver/MIMA w/ these, so why not support the out of the box?

Side-note: the legacy os-detector properties may need a revisit, see see "hack" in https://github.com/jbangdev/jbang/pull/2193

Why: it remains a nice extension, can be used as user-wide extension.

Ingest Takari Smart Builder (or Maven 4 own, but most certain is impossible due technical issues)

The current "parallel" builder is suboptimal. Smart Builder is minimal dependency (handful of classes, no transitive dependencies), and should simply replace the existing sub-optimal parallel builder.

Why: it remains a nice extension, can be used as user-wide extension.

  • No labels