Isn't this the type of change that XML Schema is supposed to enable? Perhaps
the problem is that we need to provide a downstream way to access generic
plugin specific model elements that is divorced from the POM itself? Then we
don't have to live in fear of POM changes. Just a thought...perhaps I am wrong.
Hunter
On Thursday, June 8, 2023 at 02:48:05 PM PDT, Romain Manni-Bucau
<[email protected]> wrote:
+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 <[email protected]> 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
>
