+1 to keep 3.x as this +1 to do not backward incompatible changes in v4 if possible (we regularly have the need and workaround it)
Romain Manni-Bucau @rmannibucau <https://twitter.com/rmannibucau> | Blog <https://rmannibucau.metawerx.net/> | Old Blog <http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> | LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book <https://www.packtpub.com/application-development/java-ee-8-high-performance> 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 > > > 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 > >
