On Thu, Jul 24, 2025, 09:36 Elliotte Rusty Harold <elh...@ibiblio.org> wrote:
> 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. > Nice message! Thank you for the explainer. I feel this can be sold as hardening, it's not just a design issue. >From this user's POV, I'd rather see 4.0 get this right as I expect to do migration tweaks in a major release. 5.0 feels like a million years away. Changing this in a further 4.x feels like an unexpected breaking change. HTH, Gary > 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 > >
