It helps that the consumer pom still uses the old namespace, but that's still not everything. Tools still need to analyze and understand the build pom, not just the consumer pom. For instance, organizations that are as paranoid about security as Google (and with good reason) build everything from source, and do not trust opaque binary jars. Again, organizations that large can afford to work around multiple namespaces, but I would like to make this more accessible for smaller developers that also want to build tools that try to comprehend the build structure.
The more I dig into this the more I worry that this is hiding some other questionable practices where until now no one has asked the simple question, "Why are we doing it like this?" Two in particular are starting to concern me: 1. Model versions are inferred from the namespace, enabling conflicts that wouldn't otherwise exist. A general sense of code hygiene suggests that there should be exactly one element defining the model version, and if there are two they shouldn't be allowed to disagree with each other. Otherwise, devs are in for some nasty debugging sessions where they think they've set something only to see different behavior. It's needlessly complex. 2. It's not just a 4.0 and 4.1 namespace. Large parts of Maven code appear to allow any namespace at all. E.g. http://docbook.org/ns/docbook This one might confuse tools in both directions: the ones looking for a pom and the ones looking for whatever the namespace purports to be. I'm not completely sure what the implications are here — what tools it would break or holes it might open — but it's a big world, and attackers looking to compromise systems are often more devious than me. And again we don't actually gain anything useful by allowing multiple namespaces so locking this down feels prudent. Bottom line: I'm not hearing any technical reasons why we need or should have two namespaces for what amount to the same elements. The primary objection to keeping the namespace is timing. Folks are tired, and want to ship. I sympathize with that. However, I fall on the side of the line that would prefer to see getting this right now, even at the cost of delaying 4.0, rather than living with a needlessly complex format for the remaining decades it's likely to be in the world. On Wed, Jul 23, 2025 at 6:38 PM Guillaume Nodet <gno...@apache.org> wrote: > > I think you missed an important feature of Maven 4: the consumer POM. > > In Maven 4, the consumer POM is what is deployed for the POM accompanying a > jar. > That POM has a http://maven.apache.org/POM/4.0.0 + modelVersion = 4.0.0 > so that it can be consumed by Maven 3 and other tools, gradle, ivy, etc... > This POM is rewritten from the build POM which can have a different model > version, > namespace, or language (i.e. not XML). > So if your concern is about what is deployed as POM, then you don't have to > worry about it. > > Le mer. 23 juil. 2025 à 15:37, Elliotte Rusty Harold <elh...@ibiblio.org> a > écrit : > > > 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. > > > > From the pom.xml, you have no simple way to get the dependency tree. > Computing this tree is what the resolver does, and that's definitely not a > trivial task. We've simplified the consumer POM a bit in Maven 4 by > flattening the POMs, so it's a bit easier to actually compute the effective > POM because you don't have to flatten the hierarchy. But trying to > compute the dependency tree without Maven will very probably lead to > a different tree than what Maven expects. > Other build tools tend to use Maven Resolver to actually compute the > dependency tree AFAIK. Which is also why we want Maven to be more > reusable, and that's what the Maven 4 API will provide with a single API > to access all Maven features, either internally or externally. > > > > 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. > > > > Again, that's the consumer side. We did split the consumer and the build > POM. So, yes, the Maven community is deciding how the BUILD POM is > evolving, and I think that's fine. I don't see why other people would have > to say about which feature we want to add in a particular version. > That does not affect other consumers from Maven Central at all. > > > > -- > > 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 > > > > > > -- > ------------------------ > Guillaume Nodet -- 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
