Le mer. 14 juin 2023 à 10:07, Guillaume Nodet <gno...@apache.org> a écrit :
> 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) > Actually, the schema is already relaxed wrt to required elements. It's my IDE which must be doing additional validation because the schema looks good. * 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) > Note that this would be problematic for BOM, which are pom but not used as parents. I wonder if we should clean-up this use case by using a specific "bom" packaging. This could also affect how the POM is transformed to a consumer-side BOM, as we could remove the dependencyManagement element from consumer packaged artifacts, but we'd need to keep it for consumer BOMs. > > 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 > > -- ------------------------ Guillaume Nodet
