+1 to enable it, +1000 to try to write a 4.0.0 version when possible else fail until enabled/forced in install/deploy plugins maybe?
Le jeu. 8 juin 2023 à 22:56, Guillaume Nodet <gno...@apache.org> 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 > -- > ------------------------ > Guillaume Nodet >
