Le dim. 11 juin 2023 à 23:54, Hervé Boutemy <herve.bout...@free.fr> a écrit :
> Le vendredi 9 juin 2023, 11:22:26 CEST Guillaume Nodet a écrit : > > Le ven. 9 juin 2023 à 08:59, Hervé Boutemy <herve.bout...@free.fr> a > écrit : > > > adding a new POM element in build POM was supposed to be something for > > > Maven 5 > > > and to trigger a POM 5 version, to make clear that we are leaving the > > > Maven 3 > > > space (that uses POM version 4, hence the need for version > clarification > > > between Maven and it POM model version) > > > > > > if we enter that space before having released Maven 4, we're adding > more > > > complexity: do you really want to work on Maven 5 now? > > > > > > > > > another aspect: > > > do we want to have this new improvement only for Maven 4/5 or also > have it > > > for > > > Maven 3.9? > > > in Maven 3.9, such little enhancement were implemented as XML > attributes > > > > Fwiw, if I reduce the diff between the XSD generated with 3.0 and with > > 3.9.x, I end up with the following diff > > https://gist.github.com/gnodet/f8dfd3206ebf55d6e4610a25e683120b > > So, you're right, no new elements have been introduced. A few attributes > > added, one element removed. > yes, it's a real strategy that has been defined a very long time ago, as a > strong promise from Maven project to Maven Central consumers > > > However I really don't understand how adding an attribute vs an element > > makes the POM more compatible. Our own generated parser will reject any > > unknown new attribute the same way as an unknown element (that's for any > > maven 3.x version). Here's what happen if I use a maven 3.2.5 to read a > POM > > with an element that has been introduced later: > > https://gist.github.com/gnodet/35a3ad4d449e586dc282c08eacc82ed0 > > So I'm not really buying the argument about attribute / element at this > > point. If that could be clarified, it would be nice ! > the idea is that Maven 1, 2 and 3 before 3.6.0 (MNG-6059) defined elements > only, not attributes, then people parsing POMs look at elements, not > attributes: adding attributes won't break external parsers. > 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). > > > So I think the question comes down to: do we prefer modifying/overwriting > > the schema as we did in the past or do we prefer cleanly versioning it. > In > > both cases, I think we need to keep it compatible, i.e. only add > > elements/attributes. The first option is much easier to implement: just > do > > nothing as we did in the past, but this has the drawback of not giving > > people/tools much warning or information about possible changes. We > simply > > overwrite the schema from the web site with the latest one at each > release, > > hoping that tools will not see the change and that they don't really > cache > > the schema (in case you really need the latest). The other option is to > > more properly version the schema. This would need additional code if we > > want to correctly detect which version is the lower version needed to > > correctly write a given POM. But even for doc changes, I think it may be > > preferable to micro version the schemas. > the strategy on adding new elements has always been yet to define > precisely, > and called Maven 5 > If you want to work on details of Maven 5 way to add new elements, it has > to > be worked seriously (xmlns? xsd?), documented, tested widely, ... > I'd prefer iterations that we can ship in a timely manner... My understanding is that "maven 5" was to align on a new major version of the model which is currently "4.0.0". I don't care about naming at this point. If the point is really the above, we could skip maven 4 as it has been written or use a new schema (see below). > > > The scm.child.xxx attributes that were added are not meaningful for the > > consumer afaik: they are used for build time and for doc, when you use an > > artifact as a dependency (i.e. on the consumer side), those attributes > > won't be used. So from a consumer POV, they don't carry any semantics > and > > can safely be silently discarded. This is also the case for this new > > priority attribute, as it only affects the current project or child > > projects. In that sense this new feature could just be silently added to > > the schema as previous things, so I'm fine with not versioning the schema > > now if that's the consensus. > I would not say consumers never use scm.child.xxx attributes, but yes, not > for > the core dependency aspects: if we accepted to take the risk on these > attributes, it's exactly for that reason > And yes, to me, that would be the same for plugin execution priority: not > used > by dependency consumers. > Yes, so we'd better remove them before uploading then. That's what allows the build/consumer pom. > > > > > The problem (and that's really something we need to fix), is that we > don't > > any real difference between the build POM and the consumer POM schemas. > We > > also don't make a real difference between consuming as a bom / > dependency / > > plugin, and consuming as a parent. Both cases are really different, as > the > > first one could strip out most of the <build> section. One possibility > > would be to more formerly identify those 3 use cases (build on file > system, > > consuming as a dependency and consuming as a child). Note that we're > > currently lacking a build schema, so that when using the build/consumer > > POM, your build schema cannot be validated, as it's missing some > elements. > > One possibility would be to simply make some elements non mandatory in > the > > schema. The model validation would check those anyway. For the consumer > > POM for non "pom" packaging, would it make sense to streamline the > uploaded > > POM even more: i.e. remove all build stuff from it (pluginRepositories, > > pluginManagent, plugins, reporting, etc...) or is there any use case for > > keeping those ? We could attach the build pom (i.e. we're currently > > switching the POM when installing/deploying it, but it's attached with a > > "consumer" classifier during the build). > yes, that's why Maven 4 was a first step to do and learn from it before > going > to Maven 5 > Why not, but it's currently broken because we don't have a proper schema to validate the build pom. And I don't really think that's a good idea. We can either cheat a bit again and relax the current schema, or start using a new schema, as I indicated in my other email. And if it's really about the naming, I proposed http://maven.apache.org/BUILD/4.0.0 which would keep things even more aligned, as everything would be 4.0.0 ! > Regards, > > Hervé > > > > > Guillaume > > > > > and of course, independently from this XML mapping and version details, > > > there > > > is the question to be seriously discussed about the feature itself: is > > > this > > > opportunity of introducing the "priority" field something we want (that > > > reuses > > > an implementation that is de-facto already existing internally for a > long > > > time, it just exposes it) > > > > > > Regards, > > > > > > Hervé > > > > > > Le jeudi 8 juin 2023, 22:56:27 CEST Guillaume Nodet a écrit : > > > > While working on an issue [1], I've raised a PR [2] which is adding > an > > > > > > xml > > > > > > > element to the POM. So I raised the model version to 4.2.0. My > > > > understanding is that the build/consumer POM feature [3] was created > so > > > > that we could keep compatibility. This is clearly indicated in the > wiki > > > > page: "Maven is stuck on POM v4 for a long time now, because > changing > > > > > > the > > > > > > > POM version and publishing artifacts on Maven Central with this new > > > > model > > > > would break consumers using either older Maven versions or other > build > > > > tools (that use POM v4 as a compatibility format)." > > > > > > > > However, I think this axiom is false. What happens, is that all > maven > > > > versions are perfectly capable of consuming any model when used as a > BOM > > > > > > / > > > > > > > dependency / plugin, as the parser simply ignores any unknown > attribute > > > > > > or > > > > > > > element. I can install a jar with the 4.2.0 model and consume it > with > > > > > > any > > > > > > > 3.x version without any problem. The only issue is when using that > > > > > > project > > > > > > > as a parent, in which case, the validation is strict and fails with > the > > > > 4.2.0 model. > > > > > > > > So, saying that "new model would break consumers using [...] older > Maven > > > > versions" is just wrong, as they work perfectly when consuming the > POM > > > > as > > > > dependencies. I can create a small git repo if you want to > experiment, > > > > > > but > > > > > > > that has been first checked by @cstamas, then double checked by > myself. > > > > > > > > Now, the discussion is whether we want to allow modifications to the > POM > > > > model and support new versions of it. I think this would be quite > safe, > > > > provided that there's no incompatible changes, i.e. it's only adding > new > > > > elements/attributes. > > > > I don't think this goes against the build/consumer feature, as I > think > > > > > > the > > > > > > > main benefit of this feature is to allow default values using sane > > > > conventions (mainly the project layout on the file system, which is > not > > > > available anymore in the remote repository, so this data has to be > > > > > > present > > > > > > > for consumers). > > > > > > > > So, the question: should we go ahead and allow introducing newer POM > > > > > > models > > > > > > > to bring in a few features that have been delayed for a long time > > > > because > > > > the assumption was that the model could never change ? One > possibility > > > > > > to > > > > > > > minimize the disruption would be to have a smart POM writer : i.e. it > > > > > > could > > > > > > > transform the POM to a 4.0.0 model if no new features are actually > used, > > > > > > so > > > > > > > that only projects actually using the newly introduced features would > > > > actually use the 4.x pom version. > > > > > > > > Guillaume > > > > > > > > [1] https://issues.apache.org/jira/browse/MNG-7804 > > > > [2] https://github.com/apache/maven/pull/1147 > > > > [3] > > > > > > > https://cwiki.apache.org/confluence/display/MAVEN/Build+vs+Consumer+POM > > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > 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
