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 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
