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]
