Le dim. 18 juin 2023 à 21:14, Hervé Boutemy <herve.bout...@free.fr> a écrit :
> I now understand our divergence: you implicitely use Maven 4 with some > updates > already done on xsd versions that I did not know about, and I don't yet > understand what has already be done on build vs consumer POM transformation > > First, having some feedback from people on the idea of using plugin > execution > priority would be useful, because even before diving into implementation > details, this approach is to be accepted. > > If devs agree on the introduction of basic priority, we have 3 ways to > implement its introduction: > > 1. Maven 3 way = add as an XML attribute: <element priority="100"> > Fully compatible with current Maven Central conventions, no need to change > anything > done in https://github.com/apache/maven/pull/1173 > as you can see, it's a modification of 2 lines + some documentation > Yes, but again, you say it's compatible because you add an attribute vs element. This isn't supported by any facts so far: in my mind, and in the model parser used by maven, and in the xml schema spec, there's no difference between adding an attribute and adding an element. With that in mind, I find this solution (adding an attribute vs adding an element) very inconsistent (because we don't use attributes in the schema but in a very few places) with no real benefits. And yes, it's two lines, but that's an abuse of the xml schema, because we will have to publish a newly modified schema while saying it's the same as before. How will people actually know if they have the correct one or not ? We're using checksums and all sort of things for artifacts, but we'd overwrite an existing published schema in a blink ? We don't even want to remove tags of unpublished releases and we wouldn't be scared about overwriting a schema ? and I'm not being sarcastic, I do really find that dodgy and weird that we would want to go that way. > > tested with a sample project: > https://github.com/hboutemy/MNG-7804-plugin-execution-priority > > 2. the Maven 5 way: add a new XML element, and manage the fact that it > will > change all the expectations from a Maven Central perspective > = what we were supposed to do in the future, once people have some > experience > with Maven 4 and build vs consumer POM, plus all what is required to be > added > as constraints at maven Central level > What I'm trying to say is that I don't understand why we'd need maven 4 + maven 5. The consumer POM and the definition of a new schema are two separate things and could be both done in maven 4. Also, I don't think it has been described exactly when/how the POM 5 would be used. That's what I'm trying to do in this discussion (if we can just forget about the numbers, because they have again no real meaning). > > 3. the Maven 4 way: here, I still don't get what has been already done on > POM > xmlns, POM xsd, and what is published to Maven Central > But clearly, it already opens many questions to be seriously understood on > build vs consumer POM and how this new field goes (or not) to Maven > Central in > a compatible way. Maven 4 was not supposed to change anything at Maven > Central > level. > Nothing has been done afaik. Not sure what you're referring to. > > > option 2 or 3 give me headaches > The PR remains small https://github.com/apache/maven/pull/1147 > but it is clearly defining many new ways of handling POM evolution both > internally (build vs consumer) and externally for Maven Central > At this point, I think we should avoid adding new features in 3.x and focus on 4.x. Else, it will never come out... > if one of these is chosen, I ask everybody to seriously work on it and > document all the new aspects that this reveals > Don't just say "nice" > Sure. But I'd really like to understand the constraints, because at this point, they seem to me quite unfounded and what has been done in the 3.x just breaks all the xml schema rules for versioning. > > Regards, > > Hervé > > > Le samedi 17 juin 2023, 10:07:42 CEST Guillaume Nodet a écrit : > > Le ven. 16 juin 2023, 19:20, Hervé Boutemy <herve.bout...@free.fr> a > écrit : > > > Le mercredi 14 juin 2023, 10:07:46 CEST Guillaume Nodet 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) > > > > > > > > * 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 ? > > > > > > ok for new attributes, that can simply added in POM v4.2 > > > > > > not ok for new elements: new elements are POM v5, with all the subtle > > > choices > > > to be done that you listed but I still did not have time to properly > > > evaluate, > > > and all the people who should really take time to evaluate. Notably > those > > > who > > > will have to adapt publication rules to Maven Central for POM v5. > > > > Well, v4.2 or V5, it's just a number. The point is that the url of the > > schema changes, so it's a new namespace. What is important is what we > put > > behind this number. What I'd like to come up with is a policy for > defining > > changes in the model. I don't think it would be a good idea to release > a > > new POM version and keep it in amber forever as that was the case for > > 4.0.0. Given we would have a consumer POM set in amber, the goal is to > > have more freedom for the normalized POM that will be uploaded when > > deploying parents. > > > > Also, one thing to consider, is the use of alternatives syntax/language > for > > the POM on the file system. If we want to minimize disruptions, we could > > choose to translate the POM on the file system to the normalized POM in a > > schema which would be compatible with the current schema. That's what > > polyglot has implemented and we could borrow the idea (as I demonstrated > > with the HOCON parser). > > > > So we'd have: > > * the amber'd POM 4.0.0 for consumer/flattened POMs (all packaged > > artifacts and BOMs) > > * the normalized new POM for deployed parent POMs (whatever version we > > want to give to it) > > * the build POM on the file system for which we could define alternative > > syntax > > > > Guillaume > > > > > Regards, > > > > > > Hervé > > > > > > > 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 > > > > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > > > For additional commands, e-mail: dev-h...@maven.apache.org > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > > -- ------------------------ Guillaume Nodet
