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). > 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, ... > 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 > > 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 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
