Definitely the improvement is targeting Maven 4 API, hence only plugins using Maven 4 API would benefit from it.
Backporting this to Maven 3 is nearly impossible. Basically what we have in Maven 3 (and related plugins, that fiddle with classpath/modulepath) is what we stay with in Maven 3 "universe" (i.e. "works as today does"). T On Mon, Jan 22, 2024 at 11:11 AM Martin Desruisseaux < martin.desruisse...@geomatys.com> wrote: > Le 2024-01-22 à 09 h 52, Hervé Boutemy a écrit : > > > are there known features in Maven 4 API not available in Maven 3 that > > would bring stronger interest in writing a goal for Maven 4? > > > If accepted, the way to determine where to put dependencies (class-path, > module-path, etc.) would require Maven 4 new API. It would impact > maven-compiler-plugin, maven-javadoc-plugin and maven-surefire-plugin > among others. The use of the new API by plugins would be required for > giving control to users about where to put dependencies. > > After "class-path versus module-path" issue is addressed, more may > follow. A next issue is the management of "--add-exports" options and > its friends, which would also require new API. > > > > concern: does it mean that we either should not upgrade our master > > branches to Maven 4 API too early? > > > The pull request for path management is not yet merged, and tests need > to be added. But after merged and tested, I would propose to upgrade > only three plugins at first: maven-compiler-plugin, maven-javadoc-plugin > and maven-surefire-plugin (I can volunteer for submitting patches for > them as well). After experience shows that the API works well for those > 3 plugins, other plugins could be migrated. > > > > Will we need to maintain a 3.x branch in parallel to 4/main branch? > I think yes for those who have 2 or more types of paths (e.g., > class-path and module-path options). For the other plugins, maybe not. > > Martin > >
