I finally created an ad-hoc reporting script to track Maven 4 compatibility on 
Maven's Maven 3 plugins:
https://github.com/apache/maven-dist-tool/blob/master/src/site/markdown/plugins-maven4.md

we already have 2 PRs ready to merge to fix some small incompatibilities
and a few other cases to dive into


for people interested in getting Maven 4.0.0-rc6 released then GA, please help
https://github.com/apache/maven/milestone/127

Regards,

Hervé

On 2026/03/27 14:39:03 Hervé Boutemy wrote:
> re-publishing to the expected thread:
> 
> no feedback: does it mean everybody is surprised? agrees/disagrees?
> 
> I worked on establishing the status of ASF Maven plugins:
> https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=406620656#Maven4.0.0GAchecklist-Maven4API
> 
> I all starts by establishing if existing Maven 3 plugins work with Maven 4 or 
> not: I did it for plugins that went to a Maven 4-specific branch
> 
> I think doing that check on ALL ASF Maven plugins would make sense, to 
> establish how our "Maven 3 plugins compatibility plan" works or not
> 
> and when a plugin fails initially, establishing why, and if a fix can be done 
> without creating the Maven 4 branch, would be useful
> 
> Help welcome
> 
> Hervé
> 
> 
> On 2026/03/22 03:22:14 Hervé Boutemy wrote:
> > extracting that topic, for clarity
> > 
> > my personal opinion on "It should be clear and documented why the new API 
> > is 
> > there, what it looks like / how it is used and how to upgrade to it."
> > 
> > what has to be clear is that:
> > 1. Most Maven 3.x plugins should work out of the box
> > 2. Plugins using Maven 2.x APIs will break
> > 3. Extensions are likely to need updates
> > 4. Maven 4 API Architecture: Currently flagged as experimental
> > 
> > I just extracted from slides 14 and 15 of the great slick slides:
> >  https://gnodet.github.io/maven4-presentation/
> > 
> > 
> > I'll add my own words:
> > 5. do not upgrade your Maven 3 plugins to Maven 4 API unless you get a real 
> > benefit of that effort, as you'll have to maintain 2 branches in parallel
> > 6. but test and prepare: this experimental phase is useful to check how the 
> > API is complete enough
> > 
> > We can also explain what we did at Apache Maven:
> > - created a few Maven 4-specific plugins to benefit from new features (for 
> > example Maven Compiler Plugin multi-Java module)
> > - created a test "mvn4" branch for our 50 plugins for checking: not really 
> > maintained, no backport of main branch updates, but a test
> > 
> > I'd love us to clearly document why we did a few Maven 4 plugins before 
> > Maven 
> > 4.0.0 GA: I had to dive into Java Module support to understand the Maven 
> > Compiler Plugin case
> > I'd love to get help to create a clear list of which plugins we did and why.
> > BTW this will be useful for users: "Maven 4 plugin because Maven 3 plugin 
> > does 
> > not work in Maven 4" is different from "Maven 4 plugin to benefit form some 
> > Maven 4 specific features").
> > 
> > and yes, this will also let us time to write some examples, return of 
> > experience, more doc
> > 
> > we need to remain simple and reasonable: Maven 3 plugins remain first class 
> > citizens in Maven 4
> > It's only when Maven 4 will rise that really publishing Maven 4 (specific) 
> > plugins will make sense: it will take years
> > 
> > This is the only viable way of going forward:
> > - we are not a company with resources to migrate and double maintain our 
> > own 
> > 50 plugins
> > - we will not drop our Maven 3 plugins for a good number of years
> > - there are 7.500 community plugins in Maven Central [1]: Maven 3 
> > compatibility in Maven 4 is the default path for a long time
> > - the friction of people discovering that their plugins that work in Maven 
> > 3 
> > are in fact Maven 2 plugins that were working in Maven 3 "compat mode" will 
> > be 
> > a first complexity
> > 
> > notice: I don't remember fully what Tamasz had in mind for Maven 3.10 
> > scope, 
> > but a clear WARNING "Maven 2 plugin detected: will break soon" would be 
> > useful
> > (perhaps it exists, but we don't promote it sufficiently yet)
> > 
> > 
> > We need to answer 2 questions for getting Maven 4.0.0 GA with this API 
> > topic 
> > covered:
> > 1. Is it clear?
> > 2. Do we agree? Or is there another proposal?
> > 
> > Regards,
> > 
> > Hervé
> > 
> > 
> > [1] https://central.sonatype.com/search?q=p%3Amaven-plugin
> > 
> > Le dimanche 22 février 2026, 12:09:38 CET Matthias Bünger a écrit :
> > > Hi all,
> > > I personally only care about the state of Maven API for plugin
> > > maintainers (including the Maven team). It should be clear and
> > > documented why the new API is ther, what it looks like / how it is used
> > > and how to upgrade to it. As mentioned several times and also added by
> > > Gerd to the "open To Dos for 4.0.0 list" not even our plugins are in
> > > line with the API and there a breaking changes between literally every
> > > beta/rc version. I offered several times to write documentation about
> > > this if someone tells me what I have to write, because I have no clue
> > > about the plugin API (neither for Maven 3 or 4).
> > > 
> > > I don't care about namespace changes in the build.pom. The consumer POM
> > > is unchanged so it is the same since Maven 2 and the ecosystem can work
> > > with it.
> > > 
> > > I see the possibilty that we have to do bigger changes before we are
> > > fine for a Maven 4. And maybe we need to be brave / honest enough to go
> > > back from RC phase to beta if this is required - even if it might raise
> > > the "danger" of lurkers coming out of the dark to restart discussion to
> > > add other things, like Java 21 or merge current 4.1. into 4.0 together
> > > to have mixings from the 4.0.0 start.
> > > 
> > > Other topic: I know that there is nothing like "benevolent dictator" in
> > > ASF project, but I have the feeling that we need something like this to
> > > somehow end discussions and be it only to decide to start a binding vote.
> > > 
> > > Matthias
> > 
> > 
> > 
> > 
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [email protected]
> > For additional commands, e-mail: [email protected]
> > 
> > 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [email protected]
> For additional commands, e-mail: [email protected]
> 
> 

---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to