Le jeu. 24 juil. 2025 à 17:11, Guillaume Nodet <gno...@apache.org> a écrit :
> I don't get what you're saying Romain. > > I think building a project from sources without using Maven is a bad idea, > It is more consuming the pom without maven nor resolver, this is very common and has some good reasons. My point was that for these tools you can always use maven to create the consumer pom when you do build from source so we do not break the compatibility in terms of format, we just break the fact you can't read the pom.xml from the project itself but this was broken way earlier when polyglot had been a thing. So at the end my point was that there is no relevant issue and we are good. > it kinda means reinventing maven. > Processing the build POM without relying on Maven libraries is also a bad > idea for the same reason. > Even reading the consumer POM and rebuilding the dependency tree without > Maven is a bad idea. > But there is no real alternative in several cases and it is done a lot. Agree prestaging the info with dependency plugin or alike can be a better idea but is not always possible and sometimes you want other info - like the plugins we dropped which is an issue in consumer pom ;). > > We need to make maven versatile enough to allow those usages. It has > already improved a lot with the new > API which can already be used outside the Maven runtime to build effective > model, resolve dependencies, etc.. > How do I use maven from a node or rust app without doing an exec and reusing native transport which has some advanced configuration (proxy, ciphers, certs etc)? If you are java we can debate it - but ultimately it will end with the same issues, but maven is consumed by way more data and bringing maven is often an issue, even for java apps, just cause of its stack or arch. There are even apps in container not able to write files so maven is not an option. So I think we are good and we provided mitigation mechanism (except for plugins). No need to push more until we totally drop guava and friends plus make resolver reactive where maybe we can go deeper in java integrations but today it is satisfying IMHO. > > Guillaume > > Le jeu. 24 juil. 2025 à 16:43, Romain Manni-Bucau <rmannibu...@gmail.com> > a > écrit : > > > No, when building you have the consumer pom locally too and anyway if we > > say this is an issue we just revert everything and stay on 4.0.0 which is > > very unlikely for all the reason we are discussing maven 4 so not sure we > > have the choice to be frank. > > > > 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 > > > > > > > > > Le jeu. 24 juil. 2025 à 16:38, Sylwester Lachiewicz < > slachiew...@gmail.com > > > > > a écrit : > > > > > If I understand correctly - consumer pom is for consumers that accept > > > binary artefacts. So do security reasons, if someone decides to build > it > > > internally from sources - this will not work and still needs to accept > > > different build pom styles. > > > We are aiming for build reproducibility anyway. > > > > > > Sylwester > > > > > > czw., 24 lip 2025, 16:12 użytkownik Romain Manni-Bucau < > > > rmannibu...@gmail.com> napisał: > > > > > > > Not sure it changes anything, you can still build from source, get > the > > > > consumer pom and parse it. > > > > What we should encourage for sure is to NOT do it for build pom > within > > > the > > > > project since now we can change it anytime for new features > (hopefully > > > not > > > > too often but we enabled it cause it was an issue). > > > > Also enables projects to use whatever language/syntax they want. > > > > So the only pivot format you have is the consumer pom and it doesn't > > > > require a remote repository so all good for everybody I think. > > > > > > > > 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 > > > > > > > > > > > > > > > > > Le jeu. 24 juil. 2025 à 15:50, Gary Gregory <garydgreg...@gmail.com> > a > > > > écrit : > > > > > > > > > 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 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > ------------------------ > Guillaume Nodet >
