Le mer. 21 juin 2023 à 09:27, Hervé Boutemy <herve.bout...@free.fr> a écrit :
> Le dimanche 18 juin 2023, 21:49:41 CEST Guillaume Nodet a écrit : > > 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 ? > please listen: it is a convention at Maven level defined for Maven 3.5.0 > (2017), based on the fact that we don't know the code that consumes Maven > Central > You're right: not facts based on Maven core, a compromise, not clean, you > were > not there, you just need to accept that this is history, it exists, has > reasons, is not fully stupid even if far from perfect, and you can't > change it > just at Maven core level. > The benefit is not for us on Maven core, but for the many unknown code > that > uses pom.xml from Maven Central for 20 years > > > 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. > It's a pure technical "purity" reaction that I fully respect: yes, this > compromise is dodgy from a technical point of view, but it proved to work > (it > did not break the Maven Central ecosystem consuming *.pom nor the Maven > users > writing pom.xml). > This convention has been defined in 2017, after many years searching how > to > evolve without breaking our Maven Central consumer ecosystem, with the > level > of unknown involved into judging what can reasonably be done. > This step lead later to build/consumer idea, and 2 steps: > 1. update build content, but not consumer = what is called Maven 4 > 2. update consumer content (ie in Maven Central) = what is called Maven 5 > = > the real target that will permit to solve our management of unknown POM v4 > consumers land that won't disappear and that we don't want to break. > If we introduce now some updates that were named Maven 5, I'm just trying > to > make sure we adapt our energy on sharing and checking to the increased > risk > on the whole ecosystem: as you already saw, there are edge cases at least > on > parent POMs that need to be published to Maven Central > > > > > > 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). > Maven 5 term is about making more evolution to the POM schema than adding > a > few attributes only: this has been the convention until now. > And one key basic reason was to match the POM version with Maven version > to > clarify for end users: "POM v4 for Maven 3&4, POM v5 for Maven 5" is the > motto > > You're right that what you're trying to do with only one element addition > does > not seem to deserve the 5 from core perspective: I think it will be > important > to align Maven core version with the new schema version. > POM 4.0.0 for Maven 3.x > POM ? for Maven 4.0.0 if it requires a new POM version? > > > > > > 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. > I don't know yet, perhaps this PR was the first one changing something to > the > content published to Maven Central, I still need to really study if our > mis- > alignment on Maven 4 lead inadvertently to more that what I thought. > I admit I did not review everything, there are too many fronts opened in > too > many directions for me to be sure: I would love to think that many others > did > the job, but I fear I'm not the only one who just trusted without > seriously > checking. > > Checking and clarifying what precise consumer POM is published by Maven > 4.0.0- > alpha-5 and future 4.0.0 is a priority to me, because any unexpected > change > will impact the whole ecosystem. > I thought we stayed with classical POM, ie with its xmlns, xsd (updated or > not > with the few attributes) and anything implicit that made a "classical > Maven > *.pom from Maven Central". > If we change, we'll need to make a clear summary: I'll probably write soon > a > personal sample project to clearly test and review consumer POMs generated > from build ones... This is my own way to not only describe thoughts in > plain > english, but see actual results. > > > > > > 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... > ok on that > I'll drop the 3.9.x PR, that will remain as a temporary proof of concept > of > "the old way of doing" for that plugin execution priority = the feature > that > I'd like to also have clear review from others > > > > > > 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. > please just accept our history of compromises. > Let's build and document together better approaches, ensuring our wider > Maven > Central consumer ecosystem is not hit by unexpected changes (the absolute > minimum being clearly socializing changes if we decide to change at this > point > in time) > Definitely. For the record, I agree with keeping maven central as stable as possible, I think the build/consumer POM is in general a good idea (some modifications are needed) and I'm not judging history. However, I just think that the introduction of the build/consumer can allow us to properly version the schema _and_ keep maven central stable _and_ introduce new features ! Let's close this discussion, I'll start a new fresh one later ! > > Regards, > > Hervé > > > > > > 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 > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > > -- ------------------------ Guillaume Nodet
