I actually agree that Maven's static descriptor is a strength. My interest in simplification is not about replacing XML with a DSL. I used Gradle before and eventually moved back to Maven, partly because the faster evolution and compatibility between Gradle, IDE and JDK versions created more maintenance cost for me. What I am more interested in is keeping Maven declarative and static, while making common declarations fit into one or two lines where possible.
On Fri, Aug 14, 2026 at 11:41 PM Romain Manni-Bucau <[email protected]> wrote: > Small note: one strength of maven descriptor is to be static, ie it can be > loaded whatever tooling you do use independently of the validity of the env > (parsing an XML today), I strongly think it is a killer feature compared to > gradle (which totally messes up the IDE if the build script can't be > loaded/compiled cause of a broken java version or dependency/repository > setup). Means XML, JSON(5), TOML etc are options, groovy/ruby/python are > not for example - as a standard feature, as a polyglot extension it always > had been. > Also means the verbosity is not much an issue since enclosed in tooling - > worse with LLM BTW, so even if I like the inline syntax I'm not that > convinced it is a high priority or a game changer. > > Romain Manni-Bucau > @rmannibucau <https://x.com/rmannibucau> | .NET Blog > <https://dotnetbirdie.github.io/> | Blog <https://rmannibucau.github.io/> > | Old > Blog <http://rmannibucau.wordpress.com> | Github > <https://github.com/rmannibucau> | LinkedIn > <https://www.linkedin.com/in/rmannibucau> | Book > < > https://www.packtpub.com/en-us/product/java-ee-8-high-performance-9781788473064 > > > Javaccino <https://javaccino.dev/> founder (Java/.NET service - contact > via > linkedin) > > > Le ven. 14 août 2026 à 11:49, Josh Biily <[email protected]> a > écrit : > > > Hi all, > > > > Following up on the suggestion to consolidate the historical POM/GAV > > simplification proposals, I spent some time going through the related > > issues. > > > > My original motivation was very simple: dependency lists take a lot of > > vertical space, and I wanted to see more useful information on one > > screen. > > > > After reading the historical discussions, however, I realized that the > > community has explored this topic much more deeply than simply "making > > XML shorter". > > > > I found it more useful to group the proposals by goal first, and use > > chronology inside each group. > > > > This is only a first pass. I am not trying to recommend a particular > > syntax here, but rather to collect previous thinking and understand how > > the design space has evolved. > > > > > > 1. Reduce XML verbosity while keeping XML > > ------------------------------------------ > > > > One long-running direction was to retain the existing POM structure > > while representing simple values more compactly. > > > > MNG-3397 / #5479 dates back to 2008 and broadly proposed using XML > > attributes in the POM. > > > > Related proposals include: > > > > 2009 MNG-4090 Allow attribute based configuration > > 2012 MNG-5392 Support XML attributes for simple data types in POM > > 2014 MNG-5653 POM using attributes for plugin definitions > > 2016 MNG-5996 A cleaner approach to defining dependencies > > > > A typical proposal was: > > > > <dependency groupId="org.example" artifactId="example-api" > > version="1.0.0"/> > > > > instead of: > > > > <dependency> > > <groupId>org.example</groupId> > > <artifactId>example-api</artifactId> > > <version>1.0.0</version> > > </dependency> > > > > The motivations were not only fewer characters. The discussions mention > > information density, less cursor movement, easier scanning, and making > > dependency lists easier to understand. > > > > The plugin proposal also contained forms such as: > > > > <plugin id="maven-compiler-plugin:3.1"/> > > > > which already suggests another recurring design idea: > > > > identity -> compact > > configuration -> structured > > > > > > 2. Give Maven artifacts a compact identity > > ------------------------------------------- > > > > Later proposals went beyond moving XML elements into attributes and > > asked whether Maven coordinates themselves should have a compact > > representation. > > > > MNG-7005 / #8030 proposed a Gradle-style form: > > > > <gav>groupId:artifactId:version</gav> > > > > MNG-7039 / #7998 explored a URI-like coordinate: > > > > <dependency > > uri="mvn:com.company/foo-api/1.0.1-SNAPSHOT" > > scope="compile"/> > > > > That proposal was interesting because its motivation was broader than > > POM readability: an official single-string Maven coordinate could also > > be useful for artifact identification and automation. > > > > More recently, #11500 revisited the problem. Its initial proposal was > > roughly: > > > > <dependency>groupId:artifactId:version</dependency> > > > > The discussion subsequently moved toward: > > > > <dependency id="groupId:artifactId:version"> > > ... > > </dependency> > > > > This has now resulted in PR #11904, which proposes compact id forms for > > Dependency, Exclusion and Mixin, for example: > > > > <dependency id="org.slf4j:slf4j-api:2.0.17"/> > > > > <dependency id="org.postgresql:postgresql:42.7.3"> > > <exclusions> > > <exclusion id="*:*"/> > > </exclusions> > > </dependency> > > > > <mixin id="com.example.mixins:java-mixin:1.0.0"/> > > > > As of now, that PR is still open and targeted at the 4.1.0 milestone. > > > > Looking across these proposals, there appears to be a recurring > > principle: > > > > identity -> compact > > configuration -> structured > > > > Whether id is ultimately the preferred syntax is a separate question, > > but the principle seems to recur across proposals separated by many > > years. > > > > > > 3. Make the authoring format itself replaceable > > ------------------------------------------------ > > > > MNG-6061 took a different approach. > > > > Instead of asking how XML could be made shorter, it asked whether Maven > > configuration could use alternative formats such as YAML or TOML. > > > > That changes the question from: > > > > How can XML be less verbose? > > > > to: > > > > Does the build authoring format need to be XML? > > > > Historically, this was difficult because Maven's model and its XML > > representation were tightly connected. > > > > The Maven 4 architecture changes the context considerably. ModelParser > > provides an SPI for additional model syntaxes, while the Build POM / > > Consumer POM distinction allows build-time authoring information to > > differ from the POM consumed by downstream tools. > > > > This makes alternative authoring syntax more technically feasible, > > although the ecosystem question remains: multiple equivalent formats > > also increase tooling, documentation, debugging and cognitive costs. > > > > > > 4. Simplify the model structure itself > > --------------------------------------- > > > > MNG-6230, opened in 2017 and still open, addresses a different kind of > > complexity. > > > > Its proposal explores separating plugin identity from execution > > declarations. > > > > Conceptually: > > > > plugin definition: > > what tool is being used? > > > > execution definition: > > when and how should it run? > > > > This seems important because not all POM complexity is syntactic. > > > > A POM can be concise while the underlying model is still difficult to > > reason about. > > > > So it may be useful to distinguish: > > > > syntactic complexity > > from > > structural/model complexity > > > > > > What seems to recur > > ------------------- > > > > From this first pass, I see four recurring goals: > > > > 1. Reduce XML verbosity > > 2. Compact or standardize artifact identity > > 3. Allow alternative authoring syntax > > 4. Simplify POM model/structure > > > > Within the first two areas, there is also an interesting historical > > progression: > > > > child XML elements > > -> > > XML attributes > > -> > > compact GAV > > -> > > canonical-coordinate ideas > > -> > > id="g:a:v" with structured configuration around it > > > > The motivations raised over the years include much more than typing > > less: readability, information density, artifact identity, automation, > > backward compatibility, parser/model constraints, tooling consistency > > and separation of concerns. > > > > The objections also seem to fall into two different groups. > > > > Some were historical technical constraints, for example limitations in > > Maven's model or parser architecture. > > > > Others are still design questions even if implementation is easier > > today, for example whether introducing multiple equivalent syntaxes > > increases ecosystem complexity more than it improves authoring. > > > > That distinction seems particularly relevant when revisiting these > > ideas in the Maven 4.x / 4.1 context. > > > > I am sure this consolidation is incomplete. Older discussions are > > distributed across JIRA, GitHub, mailing lists, Wiki pages and > > experiments outside Maven core. > > > > If anyone remembers important proposals that are missing, or if I have > > misunderstood the intent or outcome of any of the items above, > > corrections and additions would be very welcome. > > > > Regards, > > Billy > > > > On Fri, Aug 14, 2026 at 4:08 PM Hervé Boutemy <[email protected]> > wrote: > > > > > just landed :) > > > > > > happy that 4.0 vs 4.1 clarifies things: > > > in fact, what we currently have in 4.1 is what I called Maven 5 in 2021 > > > https://www.javaadvent.com/2021/12/from-maven-3-to-maven-5.html > > > > > > there is one key feature that initially should have waited for 4.1/5 > but > > > is in 4.0 to prepare all the plugins alongside: this is Java Module > > native > > > build (because this is strategic and we have great experts giving a lot > > of > > > efforts, experrience and time for it) > > > = > > > > > > https://cwiki.apache.org/confluence/spaces/MAVEN/pages/393677487/Full+Java+Modules+Support+-+Current+State > > > > > > > > > we have so many proposals about gav XML simplification that just > > > consolidating all good ideas that were written in the past will be a > big > > > task (search in GH issues, in Wiki, and in a lot of places) > > > whoever has the energy to start that consolidation is welcome > > > > > > Regards, > > > > > > Hervé > > > > > > On 2026/08/14 06:15:49 Josh Biily wrote: > > > > Hi Hervé, > > > > > > > > Thank you for the detailed explanation. This makes the current Maven > > 4.0 > > > > strategy much clearer to me. > > > > > > > > I especially like the distinction between "reasonable compatibility" > > and > > > > perfect compatibility. Supporting existing Maven 3 plugins enough to > > let > > > > users cross the bridge first, and then allowing Maven 4.1+ to move > more > > > > aggressively forward, sounds like a very practical approach. > > > > > > > > Your "cut the bridge behind us, not in front of us" analogy explains > > the > > > > strategy very well. > > > > > > > > I am also glad to hear that GAV/XML simplification is already being > > > > discussed internally. For everyday users, improvements like that are > > > highly > > > > visible and can make Maven 4 feel like a real new generation, not > only > > an > > > > internal architectural upgrade. > > > > > > > > I will keep an eye on RC7 and the 4.1 work. Thanks again for taking > the > > > > time to explain the plan. > > > > > > > > Best regards, > > > > Josh > > > > > > > > On Fri, Aug 14, 2026 at 12:39 PM Hervé Boutemy <[email protected]> > > > wrote: > > > > > > > > > I forgot to add a few key links: > > > > > > > > > > - we have the first layer of syntactic sugar in place in 4.0, to > > > prepare > > > > > the next ones you are asking for (that would not be reasonable for > a > > > first > > > > > step): > > > > > see https://maven.apache.org/whatsnewinmaven4.html > > > > > > > > > > - we have the compatibility tests and users migration process: > > > > > see > > https://maven.apache.org/guides/mini/guide-migration-to-mvn4.html > > > > > > > > > > - we have the first strong improvement in Maven 4.1 already > > documented > > > = > > > > > mixins, just don't talk much about it because we need to focus on > 4.0 > > > > > before 4.1: > > > > > see https://maven.apache.org/guides/mini/guide-mixins.html > > > > > > > > > > > > > > > your feedback proves me that the hard discussion about the gav XML > > > pattern > > > > > simplification should probably be our next key hot discussion... > > > > > we have people ready for that, we just asked them to ait a little > bit > > > for > > > > > now... > > > > > > > > > > > > > > > On 2026/08/14 04:28:27 Hervé Boutemy wrote: > > > > > > very good question > > > > > > > > > > > > the key topic is the huge community-provided Maven plugins: we > > cannot > > > > > just ignore them, this would be detrimental to both maintainers and > > > users > > > > > > = force new Maven 4 users to wait for every plugin maintainer to > > > create > > > > > a new Maven 4 plugin > > > > > > > > > > > > that's why we have a *reasonable* Maven 3 plugins in Maven 4 > plan. > > > > > > here, *reasonable* is key: not for Maven 3 plugins that use > Maven 2 > > > > > compatibility layer = no, that one would be too much > > > > > > > > > > > > > > > > > > We communicate a lot on this compatibilty aspect for Maven 4.0, > and > > > > > smooth transition to the new POM model, because it's a key scope > for > > a > > > > > first wave of safe usage and transition for everybody > > > > > > > > > > > > but don't worry: Maven 4.1 is in progress in parallel, with more > of > > > what > > > > > you are implicitely asking for and that we are also willing. We > just > > > had to > > > > > clarify our Maven 4.0 focus first. > > > > > > > > > > > > Maven 4.0 will be out soon with that "good" (not perfect, > > perfection > > > > > cannot be a reasonable objective) compatibility for safe transition > > > > > > > > > > > > then we can safely focus on 4.1 and more aggressive "forget Maven > > 3" > > > > > plan: we have the first step in place now to be able to cut the > > bridge > > > > > behind us, not in front of us :) > > > > > > > > > > > > > > > > > > We can go more in tech details, but this is the plan that is > > > currently > > > > > landing with good confidence: time between RC5 and 6 was too long, > > > we're > > > > > now ready for a quick RC 7 and 4.0.0 very soon > > > > > > > > > > > > Plugin maintainers, users: please help us testing with 4.0 RC6 > and > > > 4.0 > > > > > RC7, as this is the last call before 4.0 (I'm currently in an > > airport, > > > this > > > > > is the last call for my flight :) ) > > > > > > > > > > > > Hope this clarifies your good concerns > > > > > > > > > > > > Hervé > > > > > > > > > > > > On 2026/08/14 02:27:07 Josh Biily wrote: > > > > > > > Hello Maven developers, > > > > > > > > > > > > > > English is not my native language, so I hope you can understand > > if > > > some > > > > > > > wording is not perfectly precise. > > > > > > > > > > > > > > I would like to raise a design and release-strategy question > > about > > > > > Maven 4. > > > > > > > > > > > > > > This is not intended as a complaint about Maven 4 development > > > speed or > > > > > the > > > > > > > work already invested in compatibility. Maven is critical > > > > > infrastructure > > > > > > > for the Java ecosystem, and I understand why backward > > compatibility > > > > > matters. > > > > > > > > > > > > > > My question is whether Maven 4 may be carrying too much > > > compatibility > > > > > > > responsibility for Maven 3. > > > > > > > > > > > > > > My main thought is: > > > > > > > > > > > > > > Maven 3 can continue to serve existing and legacy projects, > while > > > > > Maven 4 > > > > > > > can focus more aggressively on new projects and the future Java > > > > > ecosystem. > > > > > > > > > > > > > > We already accept this model elsewhere. > > > > > > > > > > > > > > Many companies still run Java 8 applications today. Those > > projects > > > may > > > > > > > remain on Java 8 for years because stability is more important > > than > > > > > > > upgrading. That does not prevent Java 17, 21, or 25 from moving > > > > > forward. > > > > > > > > > > > > > > Spring Boot is another example. Many production systems still > use > > > > > Spring > > > > > > > Boot 2.x, while Spring Boot 3 moved to Java 17 and Jakarta EE > > with > > > > > > > significant breaking changes. Existing Boot 2 applications did > > not > > > > > need to > > > > > > > migrate immediately, but their existence did not prevent newer > > > > > generations > > > > > > > from evolving. > > > > > > > > > > > > > > Python 2 and Python 3 provide a stronger example. Old Python 2 > > > > > applications > > > > > > > could remain on Python 2 while Python 3 continued to evolve. > > > Migration > > > > > was > > > > > > > optional and happened when the benefits justified the cost. > > > > > > > > > > > > > > I wonder whether Maven could follow a similar model: > > > > > > > > > > > > > > - > > > > > > > > > > > > > > Maven 3 remains a stable maintenance line for legacy > projects. > > > > > > > - > > > > > > > > > > > > > > Existing Java 8/11 projects and old plugin ecosystems can > > > continue > > > > > using > > > > > > > Maven 3. > > > > > > > - > > > > > > > > > > > > > > Maven 4 primarily targets modern Java projects, for example > > Java > > > > > 17+. > > > > > > > - > > > > > > > > > > > > > > Maven 4 may introduce carefully chosen breaking changes when > > > they > > > > > > > provide substantial improvements in architecture, APIs, > > > performance, > > > > > > > maintainability, or developer experience. > > > > > > > - > > > > > > > > > > > > > > Projects that do not need Maven 4 are not required to > migrate. > > > > > > > - > > > > > > > > > > > > > > Projects that want Maven 4 can migrate when the benefits > > > justify it. > > > > > > > > > > > > > > In other words, backward compatibility would still be > important, > > > but > > > > > > > perhaps it could be treated partly as a migration problem > rather > > > than > > > > > as a > > > > > > > requirement that every Maven 3 project and historical behavior > > work > > > > > > > unchanged under Maven 4. > > > > > > > > > > > > > > A compatibility checker or migration tool might sometimes > provide > > > more > > > > > > > value than perfect compatibility. For example, a future tool > > could > > > > > report: > > > > > > > > > > > > > > - > > > > > > > > > > > > > > incompatible plugins > > > > > > > - > > > > > > > > > > > > > > deprecated or removed APIs > > > > > > > - > > > > > > > > > > > > > > unsupported POM behaviors > > > > > > > - > > > > > > > > > > > > > > model differences > > > > > > > - > > > > > > > > > > > > > > required migration steps > > > > > > > > > > > > > > The practical reason I think this distinction matters is that > the > > > > > projects > > > > > > > most dependent on old Maven behavior are often also the least > > > likely to > > > > > > > upgrade Maven. > > > > > > > > > > > > > > A stable Java 8 application with old plugins and a mature build > > > > > pipeline > > > > > > > may intentionally remain unchanged for many years. Ensuring > that > > > such a > > > > > > > project can use Maven 4 without modification may require > > > substantial > > > > > > > engineering effort, even though its maintainers may never plan > to > > > move > > > > > to > > > > > > > Maven 4. > > > > > > > > > > > > > > Meanwhile, new Java 21 or Java 25 projects are more likely to > > adopt > > > > > Maven 4 > > > > > > > and may benefit from improvements that are difficult to > introduce > > > under > > > > > > > very strict Maven 3 compatibility constraints. > > > > > > > > > > > > > > So perhaps the two goals could be separated more explicitly: > > > > > > > > > > > > > > Maven 3 prioritizes stability and compatibility. > > > > > > > > > > > > > > Maven 4 prioritizes forward evolution. > > > > > > > > > > > > > > These goals do not necessarily conflict. A stable Maven 3 line > > > gives > > > > > > > existing users a safe place to remain, and that stability may > > > actually > > > > > give > > > > > > > Maven 4 more freedom to evolve. > > > > > > > > > > > > > > I also think this could help Maven 4 provide more visible > > benefits > > > to > > > > > > > everyday users. > > > > > > > > > > > > > > For example, common dependency declarations are still verbose: > > > > > > > > > > > > > > <dependency> > > > > > > > <groupId>org.apache.commons</groupId> > > > > > > > <artifactId>commons-lang3</artifactId> > > > > > > > <version>3.18.0</version> > > > > > > > </dependency> > > > > > > > > > > > > > > For common cases, a future POM model could theoretically > support > > > > > syntactic > > > > > > > sugar such as: > > > > > > > > > > > > > > <gav>org.apache.commons:commons-lang3:3.18.0</gav> > > > > > > > > > > > > > > while keeping the traditional <dependency> form for complex > > cases. > > > > > > > > > > > > > > This is only an example, not the main proposal. My broader > point > > is > > > > > that a > > > > > > > major version should ideally have enough user-visible > > improvements > > > to > > > > > give > > > > > > > developers a reason to adopt it, even if some improvements > > require > > > > > > > carefully documented incompatibilities. > > > > > > > > > > > > > > I am not suggesting that Maven 4 should break compatibility > > > casually. > > > > > > > > > > > > > > I am suggesting that compatibility may benefit from having a > > > > > cost-benefit > > > > > > > threshold. If preserving a Maven 3 behavior significantly > delays > > > Maven > > > > > 4, > > > > > > > complicates its architecture, or prevents meaningful > improvements > > > for > > > > > > > modern projects, documenting the incompatibility and providing > a > > > > > migration > > > > > > > path may sometimes be the better trade-off. > > > > > > > > > > > > > > Would the Maven team consider formally treating Maven 3 as the > > > > > long-term > > > > > > > stability/compatibility line, while allowing Maven 4 more > freedom > > > for > > > > > > > carefully chosen breaking changes aimed at modern Java > projects? > > > > > > > > > > > > > > I would be interested to hear how the Maven team currently > thinks > > > about > > > > > > > this trade-off. > > > > > > > > > > > > > > Thank you for your work on Maven. > > > > > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > > > > 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] > > > > > > > > >
