I think this is exactly what Hervé explains was rejected years ago. The assumption is that the POM v4 is "set in amber" and will never change, at least for the consumer side, i.e. defining dependencies. For the build side, it has to evolve, so the POM v5 will need a different schema url or version. But imho the goals are: * make sure we keep POM v4 the way it is to tools for consumers * allow some room for POM v5 on the build side
However, the problem I see is that when you deploy a "pom" package, i.e. a parent POM that may be used as a parent for other projects, we clearly have a problem for which I do not really have a clear understanding how to solve. Let's assume this POM uses a POM v5 new feature, so that the semantic data carried by this POM can not be written with a POM v4. Such a POM can not be uploaded to maven central in the v4 form, so it WILL break tools, but I don't really see any other way. So here's what I propose: * further trim down the consumer POM as it was envisioned years ago in [1] and [2] (the removed data will still be available for other tools to consume, see below) * we want to relax the constraints of the v4 pom schema a bit to be able to validate the current build pom (where a few things are inferred) * for packaged artifacts, we will upload the consumer POM v4 as the main POM and the normalized POM v4/v5 as an attached artifact * for the "pom" package, we will upload the normalized POM v4/v5 as the main POM (no consumer POM) In the short term we could then: * allow the definition of POM v4.x, i.e. small evolutions with a schema compatible to v4 (i.e. mostly new elements / attributes) that will give a bit of freedom to implement new stuff (i.e. we should start properly versioning it and communicate to the community that they will have to adapt their tools) * when deploying the v4/v5 POM as the main POM (i.e. for pom packages), we could be smart enough to see if the POM requires non v4 features and if that's not the case, upload it as a the lower version possible (i.e. POM v4), thereby minimizing disruption for other tools scanning central (and allow consumption with maven 3.x) Longer term: * define a POM v5+ schema (with GAV as attributes, etc...) Thoughts ? Guillaume [1] https://maven.apache.org/studies/consumer-pom/maven.html [2] https://cwiki.apache.org/confluence/display/MAVEN/Build+vs+Consumer+POM Le mer. 14 juin 2023 à 08:48, Hunter C Payne <hunterpayne2...@yahoo.com.invalid> a écrit : > Sorry for chiming in again but perhaps I might have an idea. The XSD > schema that a POM uses is actually referenced from the POM. So in essence > each POM carries with it what is needed to know to parse it. Perhaps in > Maven 5 (or whichever version) we can require POM parsers to read and use > the specific XSD schema referenced in the POM. That way you can have more > room to try changes to the POM format. But there really should be a > mechanism for pushing POM changes downstream and XSD seems like a good > option for that. Sorry if this is already the plan and I'm repeating what > is already known. > > Hunter > > On Tuesday, June 13, 2023 at 11:12:39 PM PDT, Hervé Boutemy < > herve.bout...@free.fr> wrote: > > Le lundi 12 juin 2023, 01:50:56 CEST Guillaume Nodet a écrit : > > > Don't look at Maven code to judge: the whole logic is based on "known > > > unknown" > > > = we don't know who parses POMs published to Maven Central, but there > are > > > many > > > (it's easy to cite many, but not all). > > > > I can't buy that argument. You're saying that we should not assume the > way > > the POM is parsed, but we assume they don't parse arguments. That's > > clearly dodgy, and false for our own parser (both are parsed and rejected > > in strict mode and silently ignored in lenient mode). > > I can understand that it does not match the precision of your logic based > on > todays code: did you look at Maven 2 code? did you look at every other > consumer of Maven Central content? > > whatever you feel about it today, that's what has been defined and done > for now > more than 15 years, and proven working, and AFAIK checked when publishing > to > Maven Central > > If we change that, we are changing the Maven Central contract for > everybody > from the past and future > > Maven 5 is not only about Maven: it's also about Maven Central, which is > the > hardest piece to make sure we don't break usage > > Regards, > > Hervé > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > > -- ------------------------ Guillaume Nodet
