>From this user's perspective, a major release is the best time to do this, and 4.0 is the next one. Once I bump a project to 4.0 I plan on telling downstream devs that 4.0 is required, no interoperability with 3.x.
I expect that going from 3.x to 4.0 will not be 100% seamless, despite best intentions here 😉 Might as well bite the bullet IMO. Gary On Wed, Jul 23, 2025, 09:37 Elliotte Rusty Harold <elh...@ibiblio.org> wrote: > On Wed, Jul 23, 2025 at 1:07 PM Tamás Cservenák <ta...@cservenak.net> > wrote: > > > > To me your message sounds you assume model parsing == model building. > > Dependency trees and XML parsing? Analyzing what is in project? Just as > > users can use xpath or other standard tech? > > > > This is totally unrelated and POMs alone are most often even incomplete > as > > they have parents, imports and interpolation and profile activations and > so > > on. > > > > This is an important point. The Maven repository system is more than > Maven. The pom.xml is not just for Maven. Most obviously it is also > used by gradle, Ivy, bazel, and other build tools. POMs are also > consumed by static analyzers who want to figure out what dependency > trees look like, most commonly whether there are vulnerable or banned > dependencies but also for things like dependency convergence and > necessary updates. There are others, and there would be many more if > the pom format were easier to consume and process. > > At one point a large part of my day job was writing software to > analyze and understand the dependency graph of various projects. We > ended up spending probably several hundred thousand dollars worth of > engineer time because we couldn't use standard XML tools for this task > precisely due to the namespace problems. Google could afford to work > around that, but a lot of organizations can't. > > I wish the repository system and pom format were not so tightly > coupled to the Maven build tool, but that ship sailed long ago. > Ideally the decision about when and whether to revise the pom.xml > format would not be made not only by Apache Maven developers but > instead include all the stakeholders: Gradle, Sonatype, Google, > Oracle, and more. So far none of them have been heard from. We just > have a very small group of active developers of one build tool making > decisions for everyone. What we can do now is avoid making the problem > even worse by introducing additional namespace URIs beyond what we > already have. > > -- > Elliotte Rusty Harold > elh...@ibiblio.org > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > >
