You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@maven.apache.org by Guillaume Nodet <gn...@apache.org> on 2023/06/08 20:56:27 UTC
[DISCUSS] POM model version
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
Re: [DISCUSS] POM model version
Posted by Hunter C Payne <hu...@yahoo.com.INVALID>.
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 <rm...@gmail.com> 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 <gn...@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
>
Re: [DISCUSS] POM model version
Posted by Romain Manni-Bucau <rm...@gmail.com>.
+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 <gn...@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
>
Re: Build POM and consumer POM (was Re: [DISCUSS] POM model version
Posted by Hervé Boutemy <he...@free.fr>.
Le dimanche 11 juin 2023, 23:31:36 CEST Hunter C Payne a écrit :
> Strange question but maybe it will inspire someone else. Why does the POM
> the user uses to control the build the exact same format as the POMs
> created to express the results of the build? Is that necessary?
it has been done in early Maven 2 and Maven Central creation, near 20 years
ago: why do more complex? And how, when at that time all the concepts had to
be invented and implemented to simply work first.
> It seems
> to me the discussion is about the drawbacks of that approach. Perhaps its
> needed for reproducible builds or something but it seems to me those two
> use cases are different and the difficulty comes from trying to make one
> stable format serve both use cases. Hunter
that's why the concepts of build/consumer POM were introduced [1] 5 or 6 years
ago and the plan about Maven 4 and 5 [2]
with summaries of the history [3] done while working on it
Regards,
Hervé
[1] https://cwiki.apache.org/confluence/display/MAVEN/Build+vs+Consumer+POM
[2] https://cwiki.apache.org/confluence/display/MAVEN/Maven+Core+Roadmap
[3] https://www.javaadvent.com/2021/12/from-maven-3-to-maven-5.html
>
> On Sunday, June 11, 2023 at 02:12:49 PM PDT, Romain Manni-Bucau
> <rm...@gmail.com> wrote:
> Le dim. 11 juin 2023 à 22:28, Guillaume Nodet <gn...@apache.org> a écrit :
> > Those are actually two different questions, but I'd like to raise those
> > together, since they do affect the same feature.
> >
> > 1/ We currently don't have an XML schema for the build POM. One
> > possibility would be to relax a bit the constraints on the main POM schema
> > (
> > http://maven.apache.org/xsd/maven-4.0.0.xsd) so that some elements are not
> > mandatory in the xml. By not modifying the validation rules, those
> > elements will have to be present in the object model, so that should be
> > safe. Another option would be to have a separate schema, but given the
> > small set of changes on the build pom on the current constraints, i
> > think the first solution would be better. As a reminder, the build pom
> > supports: inferring version for artifacts that are part of the reactor
> > (that's usually done using managedVersion), inferring the relativePath
> > element, ci friendly interpolation for the version.
>
> +1 to relax
>
> > 2/ the consumer POM could be streamlined much more using the same
> > techniques than used in the flatten-maven-plugin. Currently, we're only
> > removing the <modules> element, but we could remove the full build
> > section,
> > flatten dependencies, etc... Packaged artifacts (i.e. with a non pom
> > packaging), can only be used as dependencies, so I think the whole
> > flattening process could make sense. Is there any drawback in doing so ?
> > Any particular reason the consumer POM support is limited to removing
> > modules and does not go further ? I can see some discussion in
> > https://cwiki.apache.org/confluence/display/MAVEN/Build+vs+Consumer+POM
> > but
> > those do not seem to be settled.
>
> Doesnt flattening break transitive dep resolution since depth changes?
>
> Also drops some build meta which cant be resoled anymore portably like
> compiler setup, which graalvm version was used and lastly would need to
> drop or not props not used elsewhere.
> Think staying as close as possible of the source is overall good to consume
> as intended (build control) until the transformer is fully configurable
> (never hopefully since it sounds overcomplicated).
>
> > Le ven. 9 juin 2023 à 11:22, Guillaume Nodet <gn...@apache.org> a écrit :
> > > Le ven. 9 juin 2023 à 08:59, Hervé Boutemy <he...@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.
> > >
> > > 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 !
> > >
> > > 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 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.
> > >
> > > 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).
> > >
> > > 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-unsubscribe@maven.apache.org
> > >> For additional commands, e-mail: dev-help@maven.apache.org
> > >
> > > --
> > > ------------------------
> > > Guillaume Nodet
> >
> > --
> > ------------------------
> > Guillaume Nodet
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Build POM and consumer POM (was Re: [DISCUSS] POM model version
Posted by Hunter C Payne <hu...@yahoo.com.INVALID>.
Strange question but maybe it will inspire someone else. Why does the POM the user uses to control the build the exact same format as the POMs created to express the results of the build? Is that necessary? It seems to me the discussion is about the drawbacks of that approach. Perhaps its needed for reproducible builds or something but it seems to me those two use cases are different and the difficulty comes from trying to make one stable format serve both use cases.
Hunter
On Sunday, June 11, 2023 at 02:12:49 PM PDT, Romain Manni-Bucau <rm...@gmail.com> wrote:
Le dim. 11 juin 2023 à 22:28, Guillaume Nodet <gn...@apache.org> a écrit :
> Those are actually two different questions, but I'd like to raise those
> together, since they do affect the same feature.
>
> 1/ We currently don't have an XML schema for the build POM. One
> possibility would be to relax a bit the constraints on the main POM schema
> (
> http://maven.apache.org/xsd/maven-4.0.0.xsd) so that some elements are not
> mandatory in the xml. By not modifying the validation rules, those
> elements will have to be present in the object model, so that should be
> safe. Another option would be to have a separate schema, but given the
> small set of changes on the build pom on the current constraints, i
> think the first solution would be better. As a reminder, the build pom
> supports: inferring version for artifacts that are part of the reactor
> (that's usually done using managedVersion), inferring the relativePath
> element, ci friendly interpolation for the version.
>
+1 to relax
>
> 2/ the consumer POM could be streamlined much more using the same
> techniques than used in the flatten-maven-plugin. Currently, we're only
> removing the <modules> element, but we could remove the full build section,
> flatten dependencies, etc... Packaged artifacts (i.e. with a non pom
> packaging), can only be used as dependencies, so I think the whole
> flattening process could make sense. Is there any drawback in doing so ?
> Any particular reason the consumer POM support is limited to removing
> modules and does not go further ? I can see some discussion in
> https://cwiki.apache.org/confluence/display/MAVEN/Build+vs+Consumer+POM
> but
> those do not seem to be settled.
>
Doesnt flattening break transitive dep resolution since depth changes?
Also drops some build meta which cant be resoled anymore portably like
compiler setup, which graalvm version was used and lastly would need to
drop or not props not used elsewhere.
Think staying as close as possible of the source is overall good to consume
as intended (build control) until the transformer is fully configurable
(never hopefully since it sounds overcomplicated).
> Le ven. 9 juin 2023 à 11:22, Guillaume Nodet <gn...@apache.org> a écrit :
>
> >
> >
> > Le ven. 9 juin 2023 à 08:59, Hervé Boutemy <he...@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.
> >
> > 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 !
> >
> > 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 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.
> >
> > 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).
> >
> > 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-unsubscribe@maven.apache.org
> >> For additional commands, e-mail: dev-help@maven.apache.org
> >>
> >>
> >
> > --
> > ------------------------
> > Guillaume Nodet
> >
> >
>
> --
> ------------------------
> Guillaume Nodet
>
Re: Build POM and consumer POM (was Re: [DISCUSS] POM model version
Posted by Hunter C Payne <hu...@yahoo.com.INVALID>.
Isn't the schema named in the POM document itself? Can't we just allow use of "extended" (read backwards compatible) schemas as the POM is versioned? Then if/once a specific schema for a use case becomes popular it can be added to parsers as the required version if needed. Or perhaps that's too complex...IDK.
Hunter
On Sunday, June 11, 2023 at 04:36:52 PM PDT, Guillaume Nodet <gn...@apache.org> wrote:
Le dim. 11 juin 2023 à 23:12, Romain Manni-Bucau <rm...@gmail.com> a
écrit :
>
>
> Le dim. 11 juin 2023 à 22:28, Guillaume Nodet <gn...@apache.org> a
> écrit :
>
>> Those are actually two different questions, but I'd like to raise those
>> together, since they do affect the same feature.
>>
>> 1/ We currently don't have an XML schema for the build POM. One
>> possibility would be to relax a bit the constraints on the main POM
>> schema (
>> http://maven.apache.org/xsd/maven-4.0.0.xsd) so that some elements are
>> not
>> mandatory in the xml. By not modifying the validation rules, those
>> elements will have to be present in the object model, so that should be
>> safe. Another option would be to have a separate schema, but given the
>> small set of changes on the build pom on the current constraints, i
>> think the first solution would be better. As a reminder, the build pom
>> supports: inferring version for artifacts that are part of the reactor
>> (that's usually done using managedVersion), inferring the relativePath
>> element, ci friendly interpolation for the version.
>>
>
> +1 to relax
>
>>
>> 2/ the consumer POM could be streamlined much more using the same
>> techniques than used in the flatten-maven-plugin. Currently, we're only
>> removing the <modules> element, but we could remove the full build
>> section,
>> flatten dependencies, etc... Packaged artifacts (i.e. with a non pom
>> packaging), can only be used as dependencies, so I think the whole
>> flattening process could make sense. Is there any drawback in doing so ?
>> Any particular reason the consumer POM support is limited to removing
>> modules and does not go further ? I can see some discussion in
>> https://cwiki.apache.org/confluence/display/MAVEN/Build+vs+Consumer+POM
>> but
>> those do not seem to be settled.
>>
>
> Doesnt flattening break transitive dep resolution since depth changes?
>
> Also drops some build meta which cant be resoled anymore portably like
> compiler setup, which graalvm version was used and lastly would need to
> drop or not props not used elsewhere.
> Think staying as close as possible of the source is overall good to
> consume as intended (build control) until the transformer is fully
> configurable (never hopefully since it sounds overcomplicated).
>
All those properties, plugin config, etc... are completely irrelevant for
jars or any other packaged artifact. The only way those can actually have
an impact is when you use the pom as a parent. That's because when you
inherit from a project, it has to have the "pom" packaging. Dependency
management is used when importing BOMs, but all other usages are afaik
limited to declaring dependencies or plugins, and in those cases, the only
interesting bits are dependencies, dependencyManagement, parents and
properties (+ repositories). The flatten-m-p does merge those 4 pieces
into a single list of dependencies (which has the benefit of simplifying
the consumption of the artifact). We may not want to do that, but still
the build section is completely irrelevant.
To recap, we have 3 different usages of the POM:
* the build pom on the file system read by maven when running
* the consumer pom on a repository which is used when consuming a
dependency/plugin jar or any other kind of packaging
* the build pom with a pom packaging which can be uploaded to central and
used as a parent by another project
I do somewhat understand the will to keep the pom schema for artifacts
uploaded in central. When consuming those jars (as dependencies or
plugins), there's definitely very little need to actually make any change
to the POM schema that they are using (even though I'm not really buying
the fact that it has to be set in "amber"). Maven already supports any new
element/attribute and other tools could adapt as well.
However, there are clear needs to improve the build side POM. The
build/pom consumer has done some improvement here, but it's not finished,
and the pain point has not been addressed in any doc/wiki page I've read so
far: if we ever introduce a new element in the build POM, but we want to
consume that POM as a parent: this is the third usage above, and it's
conflicting with two set of goals:
* introduce new stuff in the build pom
* keep 4.0.0 model in "amber"
I think the only way is to create a new schema called POM5 if you want and
to use it for build POM *and* for pom packaged POM uploaded to central,
while packaged artifacts would be stuck with POM4. The POM5 could then be
free to evolve as desired.
So to sum-up, I can see two solutions:
* allow the 4.0.0 model to evolve with 4.2.0 or any other. If we don't
touch the "consuming" side of things, old maven will still work and be able
to consumer jars uploaded (and we could still upload a 4.0.0 pom for jars
if we remove the build section and everything that's irrelevant to consume
those jars)
* introduce a new schema for the build pom (be it
http://maven.apache.org/POM/5.0.0 or http://maven.apache.org/BUILD/4.0.0,
or whatever...) and allow it's usage for build poms and consequently allow
uploading those to central for pom packaging, while packaged artifacts
could be converted to the current 4.0.0 model and stripped from the build
section)
Both solutions are roughly the same, there's not much difference: in both
cases, we need to strip out the build information from the packaged
artifacts before uploading on central (the build pom could be attached for
reference though). Then, it's just about whether we keep the current
namespace and change the version, or create a new one. It's basically a
matter of taste...
>
>
>> Le ven. 9 juin 2023 à 11:22, Guillaume Nodet <gn...@apache.org> a écrit
>> :
>>
>> >
>> >
>> > Le ven. 9 juin 2023 à 08:59, Hervé Boutemy <he...@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.
>> >
>> > 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 !
>> >
>> > 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 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.
>> >
>> > 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).
>> >
>> > 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-unsubscribe@maven.apache.org
>> >> For additional commands, e-mail: dev-help@maven.apache.org
>> >>
>> >>
>> >
>> > --
>> > ------------------------
>> > Guillaume Nodet
>> >
>> >
>>
>> --
>> ------------------------
>> Guillaume Nodet
>>
>
--
------------------------
Guillaume Nodet
Re: Build POM and consumer POM (was Re: [DISCUSS] POM model version
Posted by Romain Manni-Bucau <rm...@gmail.com>.
Le lun. 12 juin 2023 à 01:36, Guillaume Nodet <gn...@apache.org> a écrit :
> Le dim. 11 juin 2023 à 23:12, Romain Manni-Bucau <rm...@gmail.com> a
> écrit :
>
> >
> >
> > Le dim. 11 juin 2023 à 22:28, Guillaume Nodet <gn...@apache.org> a
> > écrit :
> >
> >> Those are actually two different questions, but I'd like to raise those
> >> together, since they do affect the same feature.
> >>
> >> 1/ We currently don't have an XML schema for the build POM. One
> >> possibility would be to relax a bit the constraints on the main POM
> >> schema (
> >> http://maven.apache.org/xsd/maven-4.0.0.xsd) so that some elements are
> >> not
> >> mandatory in the xml. By not modifying the validation rules, those
> >> elements will have to be present in the object model, so that should be
> >> safe. Another option would be to have a separate schema, but given the
> >> small set of changes on the build pom on the current constraints, i
> >> think the first solution would be better. As a reminder, the build pom
> >> supports: inferring version for artifacts that are part of the reactor
> >> (that's usually done using managedVersion), inferring the relativePath
> >> element, ci friendly interpolation for the version.
> >>
> >
> > +1 to relax
> >
> >>
> >> 2/ the consumer POM could be streamlined much more using the same
> >> techniques than used in the flatten-maven-plugin. Currently, we're only
> >> removing the <modules> element, but we could remove the full build
> >> section,
> >> flatten dependencies, etc... Packaged artifacts (i.e. with a non pom
> >> packaging), can only be used as dependencies, so I think the whole
> >> flattening process could make sense. Is there any drawback in doing so
> ?
> >> Any particular reason the consumer POM support is limited to removing
> >> modules and does not go further ? I can see some discussion in
> >> https://cwiki.apache.org/confluence/display/MAVEN/Build+vs+Consumer+POM
> >> but
> >> those do not seem to be settled.
> >>
> >
> > Doesnt flattening break transitive dep resolution since depth changes?
> >
> > Also drops some build meta which cant be resoled anymore portably like
> > compiler setup, which graalvm version was used and lastly would need to
> > drop or not props not used elsewhere.
> > Think staying as close as possible of the source is overall good to
> > consume as intended (build control) until the transformer is fully
> > configurable (never hopefully since it sounds overcomplicated).
> >
>
> All those properties, plugin config, etc... are completely irrelevant for
> jars or any other packaged artifact. The only way those can actually have
> an impact is when you use the pom as a parent. That's because when you
> inherit from a project, it has to have the "pom" packaging. Dependency
> management is used when importing BOMs, but all other usages are afaik
> limited to declaring dependencies or plugins, and in those cases, the only
> interesting bits are dependencies, dependencyManagement, parents and
> properties (+ repositories). The flatten-m-p does merge those 4 pieces
> into a single list of dependencies (which has the benefit of simplifying
> the consumption of the artifact). We may not want to do that, but still
> the build section is completely irrelevant.
>
Do you assume people only use pom as a dependencies source? it is used for
way more than that IMHO.
While I agree how plugins are executed is not important, how they are
configured is used and adds value to consumers.
A simple example (but trust me I saw some more complex in companie$) is to
check compiler configs to ensure the assumed based runtime will work,
indeed it is part of a static analyzis (and rarely the build) but the used
source is the deployed pom and I strongly think it is an important metadata.
Indeed you can say all that must be replaced by some metadata files but, as
of today, the pom gives that quite easily and pseudo portably (you just
compensate artifacts not using maven with explicit meta but it is a few
compared to dropping it globally).
>
> To recap, we have 3 different usages of the POM:
> * the build pom on the file system read by maven when running
> * the consumer pom on a repository which is used when consuming a
> dependency/plugin jar or any other kind of packaging
> * the build pom with a pom packaging which can be uploaded to central and
> used as a parent by another project
>
Agree
>
> I do somewhat understand the will to keep the pom schema for artifacts
> uploaded in central. When consuming those jars (as dependencies or
> plugins), there's definitely very little need to actually make any change
> to the POM schema that they are using (even though I'm not really buying
> the fact that it has to be set in "amber"). Maven already supports any new
> element/attribute and other tools could adapt as well.
> However, there are clear needs to improve the build side POM. The
> build/pom consumer has done some improvement here, but it's not finished,
> and the pain point has not been addressed in any doc/wiki page I've read so
> far: if we ever introduce a new element in the build POM, but we want to
> consume that POM as a parent: this is the third usage above, and it's
> conflicting with two set of goals:
> * introduce new stuff in the build pom
> * keep 4.0.0 model in "amber"
> I think the only way is to create a new schema called POM5 if you want and
> to use it for build POM *and* for pom packaged POM uploaded to central,
> while packaged artifacts would be stuck with POM4. The POM5 could then be
> free to evolve as desired.
>
This is where I'm not 100% sure, we should keep a build pom normalized
format (as close as v4 if possible, ex: no inline gav if we allow inline
gav in v5).
So means we can need 3 poms:
1. raw user build pom
2. consumer pom (mainly deps)
3. full deployed pom (normalized format of 1 but complete with no
flattening). Note here: we must not use the pom formatter which breaks
null/empty values as in release plugin :(.
Side note: no issue for me if version evolves or xsd evolves while shape
looks close and backward compat when possible for partial readers.
>
> So to sum-up, I can see two solutions:
> * allow the 4.0.0 model to evolve with 4.2.0 or any other. If we don't
> touch the "consuming" side of things, old maven will still work and be able
> to consumer jars uploaded (and we could still upload a 4.0.0 pom for jars
> if we remove the build section and everything that's irrelevant to consume
> those jars)
> * introduce a new schema for the build pom (be it
> http://maven.apache.org/POM/5.0.0 or http://maven.apache.org/BUILD/4.0.0,
> or whatever...) and allow it's usage for build poms and consequently allow
> uploading those to central for pom packaging, while packaged artifacts
> could be converted to the current 4.0.0 model and stripped from the build
> section)
>
> Both solutions are roughly the same, there's not much difference: in both
> cases, we need to strip out the build information from the packaged
> artifacts before uploading on central (the build pom could be attached for
> reference though). Then, it's just about whether we keep the current
> namespace and change the version, or create a new one. It's basically a
> matter of taste...
>
On my side I will not fight much on the version and way we make it evolving
but I'd like to keep the completeness of the information on central in the
most backward compat version, can just be a release plugin evolution adding
a 3rd pom as explained before but think it helps the ecosystem to not break
everything while enabling us to evolve as we wish.
Hope it makes sense
>
>
> >
> >
> >> Le ven. 9 juin 2023 à 11:22, Guillaume Nodet <gn...@apache.org> a
> écrit
> >> :
> >>
> >> >
> >> >
> >> > Le ven. 9 juin 2023 à 08:59, Hervé Boutemy <he...@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.
> >> >
> >> > 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 !
> >> >
> >> > 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 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.
> >> >
> >> > 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).
> >> >
> >> > 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-unsubscribe@maven.apache.org
> >> >> For additional commands, e-mail: dev-help@maven.apache.org
> >> >>
> >> >>
> >> >
> >> > --
> >> > ------------------------
> >> > Guillaume Nodet
> >> >
> >> >
> >>
> >> --
> >> ------------------------
> >> Guillaume Nodet
> >>
> >
>
> --
> ------------------------
> Guillaume Nodet
>
Re: Build POM and consumer POM (was Re: [DISCUSS] POM model version
Posted by Guillaume Nodet <gn...@apache.org>.
Le dim. 11 juin 2023 à 23:12, Romain Manni-Bucau <rm...@gmail.com> a
écrit :
>
>
> Le dim. 11 juin 2023 à 22:28, Guillaume Nodet <gn...@apache.org> a
> écrit :
>
>> Those are actually two different questions, but I'd like to raise those
>> together, since they do affect the same feature.
>>
>> 1/ We currently don't have an XML schema for the build POM. One
>> possibility would be to relax a bit the constraints on the main POM
>> schema (
>> http://maven.apache.org/xsd/maven-4.0.0.xsd) so that some elements are
>> not
>> mandatory in the xml. By not modifying the validation rules, those
>> elements will have to be present in the object model, so that should be
>> safe. Another option would be to have a separate schema, but given the
>> small set of changes on the build pom on the current constraints, i
>> think the first solution would be better. As a reminder, the build pom
>> supports: inferring version for artifacts that are part of the reactor
>> (that's usually done using managedVersion), inferring the relativePath
>> element, ci friendly interpolation for the version.
>>
>
> +1 to relax
>
>>
>> 2/ the consumer POM could be streamlined much more using the same
>> techniques than used in the flatten-maven-plugin. Currently, we're only
>> removing the <modules> element, but we could remove the full build
>> section,
>> flatten dependencies, etc... Packaged artifacts (i.e. with a non pom
>> packaging), can only be used as dependencies, so I think the whole
>> flattening process could make sense. Is there any drawback in doing so ?
>> Any particular reason the consumer POM support is limited to removing
>> modules and does not go further ? I can see some discussion in
>> https://cwiki.apache.org/confluence/display/MAVEN/Build+vs+Consumer+POM
>> but
>> those do not seem to be settled.
>>
>
> Doesnt flattening break transitive dep resolution since depth changes?
>
> Also drops some build meta which cant be resoled anymore portably like
> compiler setup, which graalvm version was used and lastly would need to
> drop or not props not used elsewhere.
> Think staying as close as possible of the source is overall good to
> consume as intended (build control) until the transformer is fully
> configurable (never hopefully since it sounds overcomplicated).
>
All those properties, plugin config, etc... are completely irrelevant for
jars or any other packaged artifact. The only way those can actually have
an impact is when you use the pom as a parent. That's because when you
inherit from a project, it has to have the "pom" packaging. Dependency
management is used when importing BOMs, but all other usages are afaik
limited to declaring dependencies or plugins, and in those cases, the only
interesting bits are dependencies, dependencyManagement, parents and
properties (+ repositories). The flatten-m-p does merge those 4 pieces
into a single list of dependencies (which has the benefit of simplifying
the consumption of the artifact). We may not want to do that, but still
the build section is completely irrelevant.
To recap, we have 3 different usages of the POM:
* the build pom on the file system read by maven when running
* the consumer pom on a repository which is used when consuming a
dependency/plugin jar or any other kind of packaging
* the build pom with a pom packaging which can be uploaded to central and
used as a parent by another project
I do somewhat understand the will to keep the pom schema for artifacts
uploaded in central. When consuming those jars (as dependencies or
plugins), there's definitely very little need to actually make any change
to the POM schema that they are using (even though I'm not really buying
the fact that it has to be set in "amber"). Maven already supports any new
element/attribute and other tools could adapt as well.
However, there are clear needs to improve the build side POM. The
build/pom consumer has done some improvement here, but it's not finished,
and the pain point has not been addressed in any doc/wiki page I've read so
far: if we ever introduce a new element in the build POM, but we want to
consume that POM as a parent: this is the third usage above, and it's
conflicting with two set of goals:
* introduce new stuff in the build pom
* keep 4.0.0 model in "amber"
I think the only way is to create a new schema called POM5 if you want and
to use it for build POM *and* for pom packaged POM uploaded to central,
while packaged artifacts would be stuck with POM4. The POM5 could then be
free to evolve as desired.
So to sum-up, I can see two solutions:
* allow the 4.0.0 model to evolve with 4.2.0 or any other. If we don't
touch the "consuming" side of things, old maven will still work and be able
to consumer jars uploaded (and we could still upload a 4.0.0 pom for jars
if we remove the build section and everything that's irrelevant to consume
those jars)
* introduce a new schema for the build pom (be it
http://maven.apache.org/POM/5.0.0 or http://maven.apache.org/BUILD/4.0.0,
or whatever...) and allow it's usage for build poms and consequently allow
uploading those to central for pom packaging, while packaged artifacts
could be converted to the current 4.0.0 model and stripped from the build
section)
Both solutions are roughly the same, there's not much difference: in both
cases, we need to strip out the build information from the packaged
artifacts before uploading on central (the build pom could be attached for
reference though). Then, it's just about whether we keep the current
namespace and change the version, or create a new one. It's basically a
matter of taste...
>
>
>> Le ven. 9 juin 2023 à 11:22, Guillaume Nodet <gn...@apache.org> a écrit
>> :
>>
>> >
>> >
>> > Le ven. 9 juin 2023 à 08:59, Hervé Boutemy <he...@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.
>> >
>> > 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 !
>> >
>> > 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 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.
>> >
>> > 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).
>> >
>> > 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-unsubscribe@maven.apache.org
>> >> For additional commands, e-mail: dev-help@maven.apache.org
>> >>
>> >>
>> >
>> > --
>> > ------------------------
>> > Guillaume Nodet
>> >
>> >
>>
>> --
>> ------------------------
>> Guillaume Nodet
>>
>
--
------------------------
Guillaume Nodet
Re: Build POM and consumer POM (was Re: [DISCUSS] POM model version
Posted by Romain Manni-Bucau <rm...@gmail.com>.
Le dim. 11 juin 2023 à 22:28, Guillaume Nodet <gn...@apache.org> a écrit :
> Those are actually two different questions, but I'd like to raise those
> together, since they do affect the same feature.
>
> 1/ We currently don't have an XML schema for the build POM. One
> possibility would be to relax a bit the constraints on the main POM schema
> (
> http://maven.apache.org/xsd/maven-4.0.0.xsd) so that some elements are not
> mandatory in the xml. By not modifying the validation rules, those
> elements will have to be present in the object model, so that should be
> safe. Another option would be to have a separate schema, but given the
> small set of changes on the build pom on the current constraints, i
> think the first solution would be better. As a reminder, the build pom
> supports: inferring version for artifacts that are part of the reactor
> (that's usually done using managedVersion), inferring the relativePath
> element, ci friendly interpolation for the version.
>
+1 to relax
>
> 2/ the consumer POM could be streamlined much more using the same
> techniques than used in the flatten-maven-plugin. Currently, we're only
> removing the <modules> element, but we could remove the full build section,
> flatten dependencies, etc... Packaged artifacts (i.e. with a non pom
> packaging), can only be used as dependencies, so I think the whole
> flattening process could make sense. Is there any drawback in doing so ?
> Any particular reason the consumer POM support is limited to removing
> modules and does not go further ? I can see some discussion in
> https://cwiki.apache.org/confluence/display/MAVEN/Build+vs+Consumer+POM
> but
> those do not seem to be settled.
>
Doesnt flattening break transitive dep resolution since depth changes?
Also drops some build meta which cant be resoled anymore portably like
compiler setup, which graalvm version was used and lastly would need to
drop or not props not used elsewhere.
Think staying as close as possible of the source is overall good to consume
as intended (build control) until the transformer is fully configurable
(never hopefully since it sounds overcomplicated).
> Le ven. 9 juin 2023 à 11:22, Guillaume Nodet <gn...@apache.org> a écrit :
>
> >
> >
> > Le ven. 9 juin 2023 à 08:59, Hervé Boutemy <he...@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.
> >
> > 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 !
> >
> > 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 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.
> >
> > 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).
> >
> > 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-unsubscribe@maven.apache.org
> >> For additional commands, e-mail: dev-help@maven.apache.org
> >>
> >>
> >
> > --
> > ------------------------
> > Guillaume Nodet
> >
> >
>
> --
> ------------------------
> Guillaume Nodet
>
Build POM and consumer POM (was Re: [DISCUSS] POM model version
Posted by Guillaume Nodet <gn...@apache.org>.
Those are actually two different questions, but I'd like to raise those
together, since they do affect the same feature.
1/ We currently don't have an XML schema for the build POM. One
possibility would be to relax a bit the constraints on the main POM schema (
http://maven.apache.org/xsd/maven-4.0.0.xsd) so that some elements are not
mandatory in the xml. By not modifying the validation rules, those
elements will have to be present in the object model, so that should be
safe. Another option would be to have a separate schema, but given the
small set of changes on the build pom on the current constraints, i
think the first solution would be better. As a reminder, the build pom
supports: inferring version for artifacts that are part of the reactor
(that's usually done using managedVersion), inferring the relativePath
element, ci friendly interpolation for the version.
2/ the consumer POM could be streamlined much more using the same
techniques than used in the flatten-maven-plugin. Currently, we're only
removing the <modules> element, but we could remove the full build section,
flatten dependencies, etc... Packaged artifacts (i.e. with a non pom
packaging), can only be used as dependencies, so I think the whole
flattening process could make sense. Is there any drawback in doing so ?
Any particular reason the consumer POM support is limited to removing
modules and does not go further ? I can see some discussion in
https://cwiki.apache.org/confluence/display/MAVEN/Build+vs+Consumer+POM but
those do not seem to be settled.
Le ven. 9 juin 2023 à 11:22, Guillaume Nodet <gn...@apache.org> a écrit :
>
>
> Le ven. 9 juin 2023 à 08:59, Hervé Boutemy <he...@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.
>
> 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 !
>
> 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 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.
>
> 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).
>
> 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-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>>
>
> --
> ------------------------
> Guillaume Nodet
>
>
--
------------------------
Guillaume Nodet
Re: [DISCUSS] POM model version
Posted by Guillaume Nodet <gn...@apache.org>.
Le mer. 21 juin 2023 à 09:27, Hervé Boutemy <he...@free.fr> a
écrit :
> Le dimanche 18 juin 2023, 21:49:41 CEST Guillaume Nodet a écrit :
> > Le dim. 18 juin 2023 à 21:14, Hervé Boutemy <he...@free.fr> a
> >
> > écrit :
> > > I now understand our divergence: you implicitely use Maven 4 with some
> > > updates
> > > already done on xsd versions that I did not know about, and I don't yet
> > > understand what has already be done on build vs consumer POM
> > > transformation
> > >
> > > First, having some feedback from people on the idea of using plugin
> > > execution
> > > priority would be useful, because even before diving into
> implementation
> > > details, this approach is to be accepted.
> > >
> > > If devs agree on the introduction of basic priority, we have 3 ways to
> > > implement its introduction:
> > >
> > > 1. Maven 3 way = add as an XML attribute: <element priority="100">
> > > Fully compatible with current Maven Central conventions, no need to
> change
> > > anything
> > > done in https://github.com/apache/maven/pull/1173
> > > as you can see, it's a modification of 2 lines + some documentation
> >
> > Yes, but again, you say it's compatible because you add an attribute vs
> > element. This isn't supported by any facts so far: in my mind, and in
> the
> > model parser used by maven, and in the xml schema spec, there's no
> > difference between adding an attribute and adding an element. With that
> in
> > mind, I find this solution (adding an attribute vs adding an element)
> very
> > inconsistent (because we don't use attributes in the schema but in a very
> > few places) with no real benefits. And yes, it's two lines, but that's an
> > abuse of the xml schema, because we will have to publish a newly modified
> > schema while saying it's the same as before. How will people actually
> know
> > if they have the correct one or not ?
> please listen: it is a convention at Maven level defined for Maven 3.5.0
> (2017), based on the fact that we don't know the code that consumes Maven
> Central
> You're right: not facts based on Maven core, a compromise, not clean, you
> were
> not there, you just need to accept that this is history, it exists, has
> reasons, is not fully stupid even if far from perfect, and you can't
> change it
> just at Maven core level.
> The benefit is not for us on Maven core, but for the many unknown code
> that
> uses pom.xml from Maven Central for 20 years
>
> > We're using checksums and all sort
> > of things for artifacts, but we'd overwrite an existing published schema
> in
> > a blink ? We don't even want to remove tags of unpublished releases and
> we
> > wouldn't be scared about overwriting a schema ? and I'm not being
> > sarcastic, I do really find that dodgy and weird that we would want to go
> > that way.
> It's a pure technical "purity" reaction that I fully respect: yes, this
> compromise is dodgy from a technical point of view, but it proved to work
> (it
> did not break the Maven Central ecosystem consuming *.pom nor the Maven
> users
> writing pom.xml).
> This convention has been defined in 2017, after many years searching how
> to
> evolve without breaking our Maven Central consumer ecosystem, with the
> level
> of unknown involved into judging what can reasonably be done.
> This step lead later to build/consumer idea, and 2 steps:
> 1. update build content, but not consumer = what is called Maven 4
> 2. update consumer content (ie in Maven Central) = what is called Maven 5
> =
> the real target that will permit to solve our management of unknown POM v4
> consumers land that won't disappear and that we don't want to break.
> If we introduce now some updates that were named Maven 5, I'm just trying
> to
> make sure we adapt our energy on sharing and checking to the increased
> risk
> on the whole ecosystem: as you already saw, there are edge cases at least
> on
> parent POMs that need to be published to Maven Central
>
> >
> > > tested with a sample project:
> > > https://github.com/hboutemy/MNG-7804-plugin-execution-priority
> > >
> > > 2. the Maven 5 way: add a new XML element, and manage the fact that it
> > > will
> > > change all the expectations from a Maven Central perspective
> > > = what we were supposed to do in the future, once people have some
> > > experience
> > > with Maven 4 and build vs consumer POM, plus all what is required to be
> > > added
> > > as constraints at maven Central level
> >
> > What I'm trying to say is that I don't understand why we'd need maven 4 +
> > maven 5. The consumer POM and the definition of a new schema are two
> > separate things and could be both done in maven 4. Also, I don't think
> it
> > has been described exactly when/how the POM 5 would be used. That's what
> > I'm trying to do in this discussion (if we can just forget about the
> > numbers, because they have again no real meaning).
> Maven 5 term is about making more evolution to the POM schema than adding
> a
> few attributes only: this has been the convention until now.
> And one key basic reason was to match the POM version with Maven version
> to
> clarify for end users: "POM v4 for Maven 3&4, POM v5 for Maven 5" is the
> motto
>
> You're right that what you're trying to do with only one element addition
> does
> not seem to deserve the 5 from core perspective: I think it will be
> important
> to align Maven core version with the new schema version.
> POM 4.0.0 for Maven 3.x
> POM ? for Maven 4.0.0 if it requires a new POM version?
>
> >
> > > 3. the Maven 4 way: here, I still don't get what has been already done
> on
> > > POM
> > > xmlns, POM xsd, and what is published to Maven Central
> > > But clearly, it already opens many questions to be seriously
> understood on
> > > build vs consumer POM and how this new field goes (or not) to Maven
> > > Central in
> > > a compatible way. Maven 4 was not supposed to change anything at Maven
> > > Central
> > > level.
> >
> > Nothing has been done afaik. Not sure what you're referring to.
> I don't know yet, perhaps this PR was the first one changing something to
> the
> content published to Maven Central, I still need to really study if our
> mis-
> alignment on Maven 4 lead inadvertently to more that what I thought.
> I admit I did not review everything, there are too many fronts opened in
> too
> many directions for me to be sure: I would love to think that many others
> did
> the job, but I fear I'm not the only one who just trusted without
> seriously
> checking.
>
> Checking and clarifying what precise consumer POM is published by Maven
> 4.0.0-
> alpha-5 and future 4.0.0 is a priority to me, because any unexpected
> change
> will impact the whole ecosystem.
> I thought we stayed with classical POM, ie with its xmlns, xsd (updated or
> not
> with the few attributes) and anything implicit that made a "classical
> Maven
> *.pom from Maven Central".
> If we change, we'll need to make a clear summary: I'll probably write soon
> a
> personal sample project to clearly test and review consumer POMs generated
> from build ones... This is my own way to not only describe thoughts in
> plain
> english, but see actual results.
>
> >
> > > option 2 or 3 give me headaches
> > > The PR remains small https://github.com/apache/maven/pull/1147
> > > but it is clearly defining many new ways of handling POM evolution both
> > > internally (build vs consumer) and externally for Maven Central
> >
> > At this point, I think we should avoid adding new features in 3.x and
> focus
> > on 4.x. Else, it will never come out...
> ok on that
> I'll drop the 3.9.x PR, that will remain as a temporary proof of concept
> of
> "the old way of doing" for that plugin execution priority = the feature
> that
> I'd like to also have clear review from others
>
> >
> > > if one of these is chosen, I ask everybody to seriously work on it and
> > > document all the new aspects that this reveals
> > > Don't just say "nice"
> >
> > Sure. But I'd really like to understand the constraints, because at this
> > point, they seem to me quite unfounded and what has been done in the 3.x
> > just breaks all the xml schema rules for versioning.
> please just accept our history of compromises.
> Let's build and document together better approaches, ensuring our wider
> Maven
> Central consumer ecosystem is not hit by unexpected changes (the absolute
> minimum being clearly socializing changes if we decide to change at this
> point
> in time)
>
Definitely. For the record, I agree with keeping maven central as stable
as possible, I think the build/consumer POM is in general a good idea (some
modifications are needed) and I'm not judging history. However, I just
think that the introduction of the build/consumer can allow us to properly
version the schema _and_ keep maven central stable _and_ introduce new
features !
Let's close this discussion, I'll start a new fresh one later !
>
> Regards,
>
> Hervé
>
> >
> > > Regards,
> > >
> > > Hervé
> > >
> > > Le samedi 17 juin 2023, 10:07:42 CEST Guillaume Nodet a écrit :
> > > > Le ven. 16 juin 2023, 19:20, Hervé Boutemy <he...@free.fr> a
> > >
> > > écrit :
> > > > > Le mercredi 14 juin 2023, 10:07:46 CEST Guillaume Nodet a écrit :
> > > > > > I think this is exactly what Hervé explains was rejected years
> ago.
> > >
> > > The
> > >
> > > > > > assumption is that the POM v4 is "set in amber" and will never
> > >
> > > change,
> > >
> > > > > > at
> > > > > > least for the consumer side, i.e. defining dependencies. For the
> > >
> > > build
> > >
> > > > > > side, it has to evolve, so the POM v5 will need a different
> schema
> > >
> > > url
> > >
> > > > > > or
> > > > > >
> > > > > > version. But imho the goals are:
> > > > > > * make sure we keep POM v4 the way it is to tools for consumers
> > > > > > * allow some room for POM v5 on the build side
> > > > > >
> > > > > > However, the problem I see is that when you deploy a "pom"
> package,
> > >
> > > i.e.
> > >
> > > > > a
> > > > >
> > > > > > parent POM that may be used as a parent for other projects, we
> > >
> > > clearly
> > >
> > > > > have
> > > > >
> > > > > > a problem for which I do not really have a clear understanding
> how
> > >
> > > to
> > >
> > > > > > solve. Let's assume this POM uses a POM v5 new feature, so that
> the
> > > > > > semantic data carried by this POM can not be written with a POM
> v4.
> > > > >
> > > > > Such a
> > > > >
> > > > > > POM can not be uploaded to maven central in the v4 form, so it
> WILL
> > > > > > break
> > > > > > tools, but I don't really see any other way.
> > > > > >
> > > > > > So here's what I propose:
> > > > > > * further trim down the consumer POM as it was envisioned years
> > >
> > > ago in
> > >
> > > > > > [1] and [2] (the removed data will still be available for other
> > >
> > > tools to
> > >
> > > > > > consume, see below)
> > > > > >
> > > > > > * we want to relax the constraints of the v4 pom schema a bit
> to
> > > > > > be
> > > > >
> > > > > able
> > > > >
> > > > > > to validate the current build pom (where a few things are
> inferred)
> > > > > >
> > > > > > * for packaged artifacts, we will upload the consumer POM v4 as
> > > > > > the
> > > > >
> > > > > main
> > > > >
> > > > > > POM and the normalized POM v4/v5 as an attached artifact
> > > > > >
> > > > > > * for the "pom" package, we will upload the normalized POM
> v4/v5
> > > > > > as
> > > > > > the
> > > > > >
> > > > > > main POM (no consumer POM)
> > > > > >
> > > > > > In the short term we could then:
> > > > > > * allow the definition of POM v4.x, i.e. small evolutions with
> a
> > > > > > schema
> > > > > >
> > > > > > compatible to v4 (i.e. mostly new elements / attributes) that
> will
> > >
> > > give
> > >
> > > > > > a
> > > > > > bit of freedom to implement new stuff (i.e. we should start
> properly
> > > > > > versioning it and communicate to the community that they will
> have
> > > > > > to
> > > > >
> > > > > adapt
> > > > >
> > > > > > their tools)
> > > > > >
> > > > > > * when deploying the v4/v5 POM as the main POM (i.e. for pom
> > > > > > packages),
> > > > > >
> > > > > > we could be smart enough to see if the POM requires non v4
> features
> > >
> > > and
> > >
> > > > > if
> > > > >
> > > > > > that's not the case, upload it as a the lower version possible
> (i.e.
> > >
> > > POM
> > >
> > > > > > v4), thereby minimizing disruption for other tools scanning
> central
> > >
> > > (and
> > >
> > > > > > allow consumption with maven 3.x)
> > > > > >
> > > > > > Longer term:
> > > > > > * define a POM v5+ schema (with GAV as attributes, etc...)
> > > > > >
> > > > > > Thoughts ?
> > > > >
> > > > > ok for new attributes, that can simply added in POM v4.2
> > > > >
> > > > > not ok for new elements: new elements are POM v5, with all the
> subtle
> > > > > choices
> > > > > to be done that you listed but I still did not have time to
> properly
> > > > > evaluate,
> > > > > and all the people who should really take time to evaluate. Notably
> > >
> > > those
> > >
> > > > > who
> > > > > will have to adapt publication rules to Maven Central for POM v5.
> > > >
> > > > Well, v4.2 or V5, it's just a number. The point is that the url of
> the
> > > > schema changes, so it's a new namespace. What is important is what
> we
> > >
> > > put
> > >
> > > > behind this number. What I'd like to come up with is a policy for
> > >
> > > defining
> > >
> > > > changes in the model. I don't think it would be a good idea to
> release
> > >
> > > a
> > >
> > > > new POM version and keep it in amber forever as that was the case for
> > > > 4.0.0. Given we would have a consumer POM set in amber, the goal is
> to
> > > > have more freedom for the normalized POM that will be uploaded when
> > > > deploying parents.
> > > >
> > > > Also, one thing to consider, is the use of alternatives
> syntax/language
> > >
> > > for
> > >
> > > > the POM on the file system. If we want to minimize disruptions, we
> > > > could
> > > > choose to translate the POM on the file system to the normalized POM
> in
> > > > a
> > > > schema which would be compatible with the current schema. That's
> what
> > > > polyglot has implemented and we could borrow the idea (as I
> demonstrated
> > > > with the HOCON parser).
> > > >
> > > > So we'd have:
> > > > * the amber'd POM 4.0.0 for consumer/flattened POMs (all packaged
> > > >
> > > > artifacts and BOMs)
> > > >
> > > > * the normalized new POM for deployed parent POMs (whatever version
> we
> > > >
> > > > want to give to it)
> > > >
> > > > * the build POM on the file system for which we could define
> > > > alternative
> > > >
> > > > syntax
> > > >
> > > > Guillaume
> > > >
> > > > > Regards,
> > > > >
> > > > > Hervé
> > > > >
> > > > > > Guillaume
> > > > > >
> > > > > > [1] https://maven.apache.org/studies/consumer-pom/maven.html
> > > > > > [2]
> > >
> > >
> https://cwiki.apache.org/confluence/display/MAVEN/Build+vs+Consumer+POM
> > >
> > > > > > Le mer. 14 juin 2023 à 08:48, Hunter C Payne
> > > > > >
> > > > > > <hu...@yahoo.com.invalid> a écrit :
> > > > > > > Sorry for chiming in again but perhaps I might have an idea.
> The
> > >
> > > XSD
> > >
> > > > > > > schema that a POM uses is actually referenced from the POM.
> So in
> > > > >
> > > > > essence
> > > > >
> > > > > > > each POM carries with it what is needed to know to parse it.
> > >
> > > Perhaps
> > >
> > > > > in
> > > > >
> > > > > > > Maven 5 (or whichever version) we can require POM parsers to
> read
> > >
> > > and
> > >
> > > > > use
> > > > >
> > > > > > > the specific XSD schema referenced in the POM. That way you
> can
> > >
> > > have
> > >
> > > > > more
> > > > >
> > > > > > > room to try changes to the POM format. But there really
> should be
> > >
> > > a
> > >
> > > > > > > mechanism for pushing POM changes downstream and XSD seems
> like a
> > >
> > > good
> > >
> > > > > > > option for that. Sorry if this is already the plan and I'm
> > >
> > > repeating
> > >
> > > > > what
> > > > >
> > > > > > > is already known.
> > > > > > >
> > > > > > > Hunter
> > > > > > >
> > > > > > > On Tuesday, June 13, 2023 at 11:12:39 PM PDT, Hervé
> Boutemy <
> > > > > > >
> > > > > > > herve.boutemy@free.fr> wrote:
> > > > > > > Le lundi 12 juin 2023, 01:50:56 CEST Guillaume Nodet a écrit :
> > > > > > > > > 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).
> > > > > > > >
> > > > > > > > I can't buy that argument. You're saying that we should not
> > >
> > > assume
> > >
> > > > > the
> > > > >
> > > > > > > way
> > > > > > >
> > > > > > > > the POM is parsed, but we assume they don't parse arguments.
> > >
> > > That's
> > >
> > > > > > > > clearly dodgy, and false for our own parser (both are parsed
> and
> > > > > > > > rejected
> > > > > > > > in strict mode and silently ignored in lenient mode).
> > > > > > >
> > > > > > > I can understand that it does not match the precision of your
> > > > > > > logic
> > > > >
> > > > > based
> > > > >
> > > > > > > on
> > > > > > > todays code: did you look at Maven 2 code? did you look at
> every
> > >
> > > other
> > >
> > > > > > > consumer of Maven Central content?
> > > > > > >
> > > > > > > whatever you feel about it today, that's what has been defined
> and
> > > > > > > done
> > > > > > > for now
> > > > > > > more than 15 years, and proven working, and AFAIK checked when
> > > > >
> > > > > publishing
> > > > >
> > > > > > > to
> > > > > > > Maven Central
> > > > > > >
> > > > > > > If we change that, we are changing the Maven Central contract
> for
> > > > > > > everybody
> > > > > > > from the past and future
> > > > > > >
> > > > > > > Maven 5 is not only about Maven: it's also about Maven Central,
> > >
> > > which
> > >
> > > > > is
> > > > >
> > > > > > > the
> > > > > > > hardest piece to make sure we don't break usage
> > > > > > >
> > > > > > > Regards,
> > > > > > >
> > > > > > > Hervé
> > >
> > > ---------------------------------------------------------------------
> > >
> > > > > > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > > > > > > For additional commands, e-mail: dev-help@maven.apache.org
> > > > >
> > > > >
> ---------------------------------------------------------------------
> > > > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > > > > For additional commands, e-mail: dev-help@maven.apache.org
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > > For additional commands, e-mail: dev-help@maven.apache.org
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
--
------------------------
Guillaume Nodet
Re: [DISCUSS] POM model version
Posted by Hervé Boutemy <he...@free.fr>.
Le dimanche 18 juin 2023, 21:49:41 CEST Guillaume Nodet a écrit :
> Le dim. 18 juin 2023 à 21:14, Hervé Boutemy <he...@free.fr> a
>
> écrit :
> > I now understand our divergence: you implicitely use Maven 4 with some
> > updates
> > already done on xsd versions that I did not know about, and I don't yet
> > understand what has already be done on build vs consumer POM
> > transformation
> >
> > First, having some feedback from people on the idea of using plugin
> > execution
> > priority would be useful, because even before diving into implementation
> > details, this approach is to be accepted.
> >
> > If devs agree on the introduction of basic priority, we have 3 ways to
> > implement its introduction:
> >
> > 1. Maven 3 way = add as an XML attribute: <element priority="100">
> > Fully compatible with current Maven Central conventions, no need to change
> > anything
> > done in https://github.com/apache/maven/pull/1173
> > as you can see, it's a modification of 2 lines + some documentation
>
> Yes, but again, you say it's compatible because you add an attribute vs
> element. This isn't supported by any facts so far: in my mind, and in the
> model parser used by maven, and in the xml schema spec, there's no
> difference between adding an attribute and adding an element. With that in
> mind, I find this solution (adding an attribute vs adding an element) very
> inconsistent (because we don't use attributes in the schema but in a very
> few places) with no real benefits. And yes, it's two lines, but that's an
> abuse of the xml schema, because we will have to publish a newly modified
> schema while saying it's the same as before. How will people actually know
> if they have the correct one or not ?
please listen: it is a convention at Maven level defined for Maven 3.5.0
(2017), based on the fact that we don't know the code that consumes Maven
Central
You're right: not facts based on Maven core, a compromise, not clean, you were
not there, you just need to accept that this is history, it exists, has
reasons, is not fully stupid even if far from perfect, and you can't change it
just at Maven core level.
The benefit is not for us on Maven core, but for the many unknown code that
uses pom.xml from Maven Central for 20 years
> We're using checksums and all sort
> of things for artifacts, but we'd overwrite an existing published schema in
> a blink ? We don't even want to remove tags of unpublished releases and we
> wouldn't be scared about overwriting a schema ? and I'm not being
> sarcastic, I do really find that dodgy and weird that we would want to go
> that way.
It's a pure technical "purity" reaction that I fully respect: yes, this
compromise is dodgy from a technical point of view, but it proved to work (it
did not break the Maven Central ecosystem consuming *.pom nor the Maven users
writing pom.xml).
This convention has been defined in 2017, after many years searching how to
evolve without breaking our Maven Central consumer ecosystem, with the level
of unknown involved into judging what can reasonably be done.
This step lead later to build/consumer idea, and 2 steps:
1. update build content, but not consumer = what is called Maven 4
2. update consumer content (ie in Maven Central) = what is called Maven 5 =
the real target that will permit to solve our management of unknown POM v4
consumers land that won't disappear and that we don't want to break.
If we introduce now some updates that were named Maven 5, I'm just trying to
make sure we adapt our energy on sharing and checking to the increased risk
on the whole ecosystem: as you already saw, there are edge cases at least on
parent POMs that need to be published to Maven Central
>
> > tested with a sample project:
> > https://github.com/hboutemy/MNG-7804-plugin-execution-priority
> >
> > 2. the Maven 5 way: add a new XML element, and manage the fact that it
> > will
> > change all the expectations from a Maven Central perspective
> > = what we were supposed to do in the future, once people have some
> > experience
> > with Maven 4 and build vs consumer POM, plus all what is required to be
> > added
> > as constraints at maven Central level
>
> What I'm trying to say is that I don't understand why we'd need maven 4 +
> maven 5. The consumer POM and the definition of a new schema are two
> separate things and could be both done in maven 4. Also, I don't think it
> has been described exactly when/how the POM 5 would be used. That's what
> I'm trying to do in this discussion (if we can just forget about the
> numbers, because they have again no real meaning).
Maven 5 term is about making more evolution to the POM schema than adding a
few attributes only: this has been the convention until now.
And one key basic reason was to match the POM version with Maven version to
clarify for end users: "POM v4 for Maven 3&4, POM v5 for Maven 5" is the motto
You're right that what you're trying to do with only one element addition does
not seem to deserve the 5 from core perspective: I think it will be important
to align Maven core version with the new schema version.
POM 4.0.0 for Maven 3.x
POM ? for Maven 4.0.0 if it requires a new POM version?
>
> > 3. the Maven 4 way: here, I still don't get what has been already done on
> > POM
> > xmlns, POM xsd, and what is published to Maven Central
> > But clearly, it already opens many questions to be seriously understood on
> > build vs consumer POM and how this new field goes (or not) to Maven
> > Central in
> > a compatible way. Maven 4 was not supposed to change anything at Maven
> > Central
> > level.
>
> Nothing has been done afaik. Not sure what you're referring to.
I don't know yet, perhaps this PR was the first one changing something to the
content published to Maven Central, I still need to really study if our mis-
alignment on Maven 4 lead inadvertently to more that what I thought.
I admit I did not review everything, there are too many fronts opened in too
many directions for me to be sure: I would love to think that many others did
the job, but I fear I'm not the only one who just trusted without seriously
checking.
Checking and clarifying what precise consumer POM is published by Maven 4.0.0-
alpha-5 and future 4.0.0 is a priority to me, because any unexpected change
will impact the whole ecosystem.
I thought we stayed with classical POM, ie with its xmlns, xsd (updated or not
with the few attributes) and anything implicit that made a "classical Maven
*.pom from Maven Central".
If we change, we'll need to make a clear summary: I'll probably write soon a
personal sample project to clearly test and review consumer POMs generated
from build ones... This is my own way to not only describe thoughts in plain
english, but see actual results.
>
> > option 2 or 3 give me headaches
> > The PR remains small https://github.com/apache/maven/pull/1147
> > but it is clearly defining many new ways of handling POM evolution both
> > internally (build vs consumer) and externally for Maven Central
>
> At this point, I think we should avoid adding new features in 3.x and focus
> on 4.x. Else, it will never come out...
ok on that
I'll drop the 3.9.x PR, that will remain as a temporary proof of concept of
"the old way of doing" for that plugin execution priority = the feature that
I'd like to also have clear review from others
>
> > if one of these is chosen, I ask everybody to seriously work on it and
> > document all the new aspects that this reveals
> > Don't just say "nice"
>
> Sure. But I'd really like to understand the constraints, because at this
> point, they seem to me quite unfounded and what has been done in the 3.x
> just breaks all the xml schema rules for versioning.
please just accept our history of compromises.
Let's build and document together better approaches, ensuring our wider Maven
Central consumer ecosystem is not hit by unexpected changes (the absolute
minimum being clearly socializing changes if we decide to change at this point
in time)
Regards,
Hervé
>
> > Regards,
> >
> > Hervé
> >
> > Le samedi 17 juin 2023, 10:07:42 CEST Guillaume Nodet a écrit :
> > > Le ven. 16 juin 2023, 19:20, Hervé Boutemy <he...@free.fr> a
> >
> > écrit :
> > > > Le mercredi 14 juin 2023, 10:07:46 CEST Guillaume Nodet a écrit :
> > > > > I think this is exactly what Hervé explains was rejected years ago.
> >
> > The
> >
> > > > > assumption is that the POM v4 is "set in amber" and will never
> >
> > change,
> >
> > > > > at
> > > > > least for the consumer side, i.e. defining dependencies. For the
> >
> > build
> >
> > > > > side, it has to evolve, so the POM v5 will need a different schema
> >
> > url
> >
> > > > > or
> > > > >
> > > > > version. But imho the goals are:
> > > > > * make sure we keep POM v4 the way it is to tools for consumers
> > > > > * allow some room for POM v5 on the build side
> > > > >
> > > > > However, the problem I see is that when you deploy a "pom" package,
> >
> > i.e.
> >
> > > > a
> > > >
> > > > > parent POM that may be used as a parent for other projects, we
> >
> > clearly
> >
> > > > have
> > > >
> > > > > a problem for which I do not really have a clear understanding how
> >
> > to
> >
> > > > > solve. Let's assume this POM uses a POM v5 new feature, so that the
> > > > > semantic data carried by this POM can not be written with a POM v4.
> > > >
> > > > Such a
> > > >
> > > > > POM can not be uploaded to maven central in the v4 form, so it WILL
> > > > > break
> > > > > tools, but I don't really see any other way.
> > > > >
> > > > > So here's what I propose:
> > > > > * further trim down the consumer POM as it was envisioned years
> >
> > ago in
> >
> > > > > [1] and [2] (the removed data will still be available for other
> >
> > tools to
> >
> > > > > consume, see below)
> > > > >
> > > > > * we want to relax the constraints of the v4 pom schema a bit to
> > > > > be
> > > >
> > > > able
> > > >
> > > > > to validate the current build pom (where a few things are inferred)
> > > > >
> > > > > * for packaged artifacts, we will upload the consumer POM v4 as
> > > > > the
> > > >
> > > > main
> > > >
> > > > > POM and the normalized POM v4/v5 as an attached artifact
> > > > >
> > > > > * for the "pom" package, we will upload the normalized POM v4/v5
> > > > > as
> > > > > the
> > > > >
> > > > > main POM (no consumer POM)
> > > > >
> > > > > In the short term we could then:
> > > > > * allow the definition of POM v4.x, i.e. small evolutions with a
> > > > > schema
> > > > >
> > > > > compatible to v4 (i.e. mostly new elements / attributes) that will
> >
> > give
> >
> > > > > a
> > > > > bit of freedom to implement new stuff (i.e. we should start properly
> > > > > versioning it and communicate to the community that they will have
> > > > > to
> > > >
> > > > adapt
> > > >
> > > > > their tools)
> > > > >
> > > > > * when deploying the v4/v5 POM as the main POM (i.e. for pom
> > > > > packages),
> > > > >
> > > > > we could be smart enough to see if the POM requires non v4 features
> >
> > and
> >
> > > > if
> > > >
> > > > > that's not the case, upload it as a the lower version possible (i.e.
> >
> > POM
> >
> > > > > v4), thereby minimizing disruption for other tools scanning central
> >
> > (and
> >
> > > > > allow consumption with maven 3.x)
> > > > >
> > > > > Longer term:
> > > > > * define a POM v5+ schema (with GAV as attributes, etc...)
> > > > >
> > > > > Thoughts ?
> > > >
> > > > ok for new attributes, that can simply added in POM v4.2
> > > >
> > > > not ok for new elements: new elements are POM v5, with all the subtle
> > > > choices
> > > > to be done that you listed but I still did not have time to properly
> > > > evaluate,
> > > > and all the people who should really take time to evaluate. Notably
> >
> > those
> >
> > > > who
> > > > will have to adapt publication rules to Maven Central for POM v5.
> > >
> > > Well, v4.2 or V5, it's just a number. The point is that the url of the
> > > schema changes, so it's a new namespace. What is important is what we
> >
> > put
> >
> > > behind this number. What I'd like to come up with is a policy for
> >
> > defining
> >
> > > changes in the model. I don't think it would be a good idea to release
> >
> > a
> >
> > > new POM version and keep it in amber forever as that was the case for
> > > 4.0.0. Given we would have a consumer POM set in amber, the goal is to
> > > have more freedom for the normalized POM that will be uploaded when
> > > deploying parents.
> > >
> > > Also, one thing to consider, is the use of alternatives syntax/language
> >
> > for
> >
> > > the POM on the file system. If we want to minimize disruptions, we
> > > could
> > > choose to translate the POM on the file system to the normalized POM in
> > > a
> > > schema which would be compatible with the current schema. That's what
> > > polyglot has implemented and we could borrow the idea (as I demonstrated
> > > with the HOCON parser).
> > >
> > > So we'd have:
> > > * the amber'd POM 4.0.0 for consumer/flattened POMs (all packaged
> > >
> > > artifacts and BOMs)
> > >
> > > * the normalized new POM for deployed parent POMs (whatever version we
> > >
> > > want to give to it)
> > >
> > > * the build POM on the file system for which we could define
> > > alternative
> > >
> > > syntax
> > >
> > > Guillaume
> > >
> > > > Regards,
> > > >
> > > > Hervé
> > > >
> > > > > Guillaume
> > > > >
> > > > > [1] https://maven.apache.org/studies/consumer-pom/maven.html
> > > > > [2]
> >
> > https://cwiki.apache.org/confluence/display/MAVEN/Build+vs+Consumer+POM
> >
> > > > > Le mer. 14 juin 2023 à 08:48, Hunter C Payne
> > > > >
> > > > > <hu...@yahoo.com.invalid> a écrit :
> > > > > > Sorry for chiming in again but perhaps I might have an idea. The
> >
> > XSD
> >
> > > > > > schema that a POM uses is actually referenced from the POM. So in
> > > >
> > > > essence
> > > >
> > > > > > each POM carries with it what is needed to know to parse it.
> >
> > Perhaps
> >
> > > > in
> > > >
> > > > > > Maven 5 (or whichever version) we can require POM parsers to read
> >
> > and
> >
> > > > use
> > > >
> > > > > > the specific XSD schema referenced in the POM. That way you can
> >
> > have
> >
> > > > more
> > > >
> > > > > > room to try changes to the POM format. But there really should be
> >
> > a
> >
> > > > > > mechanism for pushing POM changes downstream and XSD seems like a
> >
> > good
> >
> > > > > > option for that. Sorry if this is already the plan and I'm
> >
> > repeating
> >
> > > > what
> > > >
> > > > > > is already known.
> > > > > >
> > > > > > Hunter
> > > > > >
> > > > > > On Tuesday, June 13, 2023 at 11:12:39 PM PDT, Hervé Boutemy <
> > > > > >
> > > > > > herve.boutemy@free.fr> wrote:
> > > > > > Le lundi 12 juin 2023, 01:50:56 CEST Guillaume Nodet a écrit :
> > > > > > > > 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).
> > > > > > >
> > > > > > > I can't buy that argument. You're saying that we should not
> >
> > assume
> >
> > > > the
> > > >
> > > > > > way
> > > > > >
> > > > > > > the POM is parsed, but we assume they don't parse arguments.
> >
> > That's
> >
> > > > > > > clearly dodgy, and false for our own parser (both are parsed and
> > > > > > > rejected
> > > > > > > in strict mode and silently ignored in lenient mode).
> > > > > >
> > > > > > I can understand that it does not match the precision of your
> > > > > > logic
> > > >
> > > > based
> > > >
> > > > > > on
> > > > > > todays code: did you look at Maven 2 code? did you look at every
> >
> > other
> >
> > > > > > consumer of Maven Central content?
> > > > > >
> > > > > > whatever you feel about it today, that's what has been defined and
> > > > > > done
> > > > > > for now
> > > > > > more than 15 years, and proven working, and AFAIK checked when
> > > >
> > > > publishing
> > > >
> > > > > > to
> > > > > > Maven Central
> > > > > >
> > > > > > If we change that, we are changing the Maven Central contract for
> > > > > > everybody
> > > > > > from the past and future
> > > > > >
> > > > > > Maven 5 is not only about Maven: it's also about Maven Central,
> >
> > which
> >
> > > > is
> > > >
> > > > > > the
> > > > > > hardest piece to make sure we don't break usage
> > > > > >
> > > > > > Regards,
> > > > > >
> > > > > > Hervé
> >
> > ---------------------------------------------------------------------
> >
> > > > > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > > > > > For additional commands, e-mail: dev-help@maven.apache.org
> > > >
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > > > For additional commands, e-mail: dev-help@maven.apache.org
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [DISCUSS] POM model version
Posted by Guillaume Nodet <gn...@apache.org>.
Le dim. 18 juin 2023 à 21:14, Hervé Boutemy <he...@free.fr> a
écrit :
> I now understand our divergence: you implicitely use Maven 4 with some
> updates
> already done on xsd versions that I did not know about, and I don't yet
> understand what has already be done on build vs consumer POM transformation
>
> First, having some feedback from people on the idea of using plugin
> execution
> priority would be useful, because even before diving into implementation
> details, this approach is to be accepted.
>
> If devs agree on the introduction of basic priority, we have 3 ways to
> implement its introduction:
>
> 1. Maven 3 way = add as an XML attribute: <element priority="100">
> Fully compatible with current Maven Central conventions, no need to change
> anything
> done in https://github.com/apache/maven/pull/1173
> as you can see, it's a modification of 2 lines + some documentation
>
Yes, but again, you say it's compatible because you add an attribute vs
element. This isn't supported by any facts so far: in my mind, and in the
model parser used by maven, and in the xml schema spec, there's no
difference between adding an attribute and adding an element. With that in
mind, I find this solution (adding an attribute vs adding an element) very
inconsistent (because we don't use attributes in the schema but in a very
few places) with no real benefits. And yes, it's two lines, but that's an
abuse of the xml schema, because we will have to publish a newly modified
schema while saying it's the same as before. How will people actually know
if they have the correct one or not ? We're using checksums and all sort
of things for artifacts, but we'd overwrite an existing published schema in
a blink ? We don't even want to remove tags of unpublished releases and we
wouldn't be scared about overwriting a schema ? and I'm not being
sarcastic, I do really find that dodgy and weird that we would want to go
that way.
>
> tested with a sample project:
> https://github.com/hboutemy/MNG-7804-plugin-execution-priority
>
> 2. the Maven 5 way: add a new XML element, and manage the fact that it
> will
> change all the expectations from a Maven Central perspective
> = what we were supposed to do in the future, once people have some
> experience
> with Maven 4 and build vs consumer POM, plus all what is required to be
> added
> as constraints at maven Central level
>
What I'm trying to say is that I don't understand why we'd need maven 4 +
maven 5. The consumer POM and the definition of a new schema are two
separate things and could be both done in maven 4. Also, I don't think it
has been described exactly when/how the POM 5 would be used. That's what
I'm trying to do in this discussion (if we can just forget about the
numbers, because they have again no real meaning).
>
> 3. the Maven 4 way: here, I still don't get what has been already done on
> POM
> xmlns, POM xsd, and what is published to Maven Central
> But clearly, it already opens many questions to be seriously understood on
> build vs consumer POM and how this new field goes (or not) to Maven
> Central in
> a compatible way. Maven 4 was not supposed to change anything at Maven
> Central
> level.
>
Nothing has been done afaik. Not sure what you're referring to.
>
>
> option 2 or 3 give me headaches
> The PR remains small https://github.com/apache/maven/pull/1147
> but it is clearly defining many new ways of handling POM evolution both
> internally (build vs consumer) and externally for Maven Central
>
At this point, I think we should avoid adding new features in 3.x and focus
on 4.x. Else, it will never come out...
> if one of these is chosen, I ask everybody to seriously work on it and
> document all the new aspects that this reveals
> Don't just say "nice"
>
Sure. But I'd really like to understand the constraints, because at this
point, they seem to me quite unfounded and what has been done in the 3.x
just breaks all the xml schema rules for versioning.
>
> Regards,
>
> Hervé
>
>
> Le samedi 17 juin 2023, 10:07:42 CEST Guillaume Nodet a écrit :
> > Le ven. 16 juin 2023, 19:20, Hervé Boutemy <he...@free.fr> a
> écrit :
> > > Le mercredi 14 juin 2023, 10:07:46 CEST Guillaume Nodet a écrit :
> > > > I think this is exactly what Hervé explains was rejected years ago.
> The
> > > > assumption is that the POM v4 is "set in amber" and will never
> change,
> > > > at
> > > > least for the consumer side, i.e. defining dependencies. For the
> build
> > > > side, it has to evolve, so the POM v5 will need a different schema
> url
> > > > or
> > > >
> > > > version. But imho the goals are:
> > > > * make sure we keep POM v4 the way it is to tools for consumers
> > > > * allow some room for POM v5 on the build side
> > > >
> > > > However, the problem I see is that when you deploy a "pom" package,
> i.e.
> > >
> > > a
> > >
> > > > parent POM that may be used as a parent for other projects, we
> clearly
> > >
> > > have
> > >
> > > > a problem for which I do not really have a clear understanding how
> to
> > > > solve. Let's assume this POM uses a POM v5 new feature, so that the
> > > > semantic data carried by this POM can not be written with a POM v4.
> > >
> > > Such a
> > >
> > > > POM can not be uploaded to maven central in the v4 form, so it WILL
> > > > break
> > > > tools, but I don't really see any other way.
> > > >
> > > > So here's what I propose:
> > > > * further trim down the consumer POM as it was envisioned years
> ago in
> > > >
> > > > [1] and [2] (the removed data will still be available for other
> tools to
> > > > consume, see below)
> > > >
> > > > * we want to relax the constraints of the v4 pom schema a bit to be
> > >
> > > able
> > >
> > > > to validate the current build pom (where a few things are inferred)
> > > >
> > > > * for packaged artifacts, we will upload the consumer POM v4 as the
> > >
> > > main
> > >
> > > > POM and the normalized POM v4/v5 as an attached artifact
> > > >
> > > > * for the "pom" package, we will upload the normalized POM v4/v5 as
> > > > the
> > > >
> > > > main POM (no consumer POM)
> > > >
> > > > In the short term we could then:
> > > > * allow the definition of POM v4.x, i.e. small evolutions with a
> > > > schema
> > > >
> > > > compatible to v4 (i.e. mostly new elements / attributes) that will
> give
> > > > a
> > > > bit of freedom to implement new stuff (i.e. we should start properly
> > > > versioning it and communicate to the community that they will have to
> > >
> > > adapt
> > >
> > > > their tools)
> > > >
> > > > * when deploying the v4/v5 POM as the main POM (i.e. for pom
> > > > packages),
> > > >
> > > > we could be smart enough to see if the POM requires non v4 features
> and
> > >
> > > if
> > >
> > > > that's not the case, upload it as a the lower version possible (i.e.
> POM
> > > > v4), thereby minimizing disruption for other tools scanning central
> (and
> > > > allow consumption with maven 3.x)
> > > >
> > > > Longer term:
> > > > * define a POM v5+ schema (with GAV as attributes, etc...)
> > > >
> > > > Thoughts ?
> > >
> > > ok for new attributes, that can simply added in POM v4.2
> > >
> > > not ok for new elements: new elements are POM v5, with all the subtle
> > > choices
> > > to be done that you listed but I still did not have time to properly
> > > evaluate,
> > > and all the people who should really take time to evaluate. Notably
> those
> > > who
> > > will have to adapt publication rules to Maven Central for POM v5.
> >
> > Well, v4.2 or V5, it's just a number. The point is that the url of the
> > schema changes, so it's a new namespace. What is important is what we
> put
> > behind this number. What I'd like to come up with is a policy for
> defining
> > changes in the model. I don't think it would be a good idea to release
> a
> > new POM version and keep it in amber forever as that was the case for
> > 4.0.0. Given we would have a consumer POM set in amber, the goal is to
> > have more freedom for the normalized POM that will be uploaded when
> > deploying parents.
> >
> > Also, one thing to consider, is the use of alternatives syntax/language
> for
> > the POM on the file system. If we want to minimize disruptions, we could
> > choose to translate the POM on the file system to the normalized POM in a
> > schema which would be compatible with the current schema. That's what
> > polyglot has implemented and we could borrow the idea (as I demonstrated
> > with the HOCON parser).
> >
> > So we'd have:
> > * the amber'd POM 4.0.0 for consumer/flattened POMs (all packaged
> > artifacts and BOMs)
> > * the normalized new POM for deployed parent POMs (whatever version we
> > want to give to it)
> > * the build POM on the file system for which we could define alternative
> > syntax
> >
> > Guillaume
> >
> > > Regards,
> > >
> > > Hervé
> > >
> > > > Guillaume
> > > >
> > > > [1] https://maven.apache.org/studies/consumer-pom/maven.html
> > > > [2]
> > >
> > >
> https://cwiki.apache.org/confluence/display/MAVEN/Build+vs+Consumer+POM
> > >
> > > > Le mer. 14 juin 2023 à 08:48, Hunter C Payne
> > > >
> > > > <hu...@yahoo.com.invalid> a écrit :
> > > > > Sorry for chiming in again but perhaps I might have an idea. The
> XSD
> > > > >
> > > > > schema that a POM uses is actually referenced from the POM. So in
> > >
> > > essence
> > >
> > > > > each POM carries with it what is needed to know to parse it.
> Perhaps
> > >
> > > in
> > >
> > > > > Maven 5 (or whichever version) we can require POM parsers to read
> and
> > >
> > > use
> > >
> > > > > the specific XSD schema referenced in the POM. That way you can
> have
> > >
> > > more
> > >
> > > > > room to try changes to the POM format. But there really should be
> a
> > > > > mechanism for pushing POM changes downstream and XSD seems like a
> good
> > > > > option for that. Sorry if this is already the plan and I'm
> repeating
> > >
> > > what
> > >
> > > > > is already known.
> > > > >
> > > > > Hunter
> > > > >
> > > > > On Tuesday, June 13, 2023 at 11:12:39 PM PDT, Hervé Boutemy <
> > > > >
> > > > > herve.boutemy@free.fr> wrote:
> > > > > Le lundi 12 juin 2023, 01:50:56 CEST Guillaume Nodet a écrit :
> > > > > > > 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).
> > > > > >
> > > > > > I can't buy that argument. You're saying that we should not
> assume
> > >
> > > the
> > >
> > > > > way
> > > > >
> > > > > > the POM is parsed, but we assume they don't parse arguments.
> That's
> > > > > > clearly dodgy, and false for our own parser (both are parsed and
> > > > > > rejected
> > > > > > in strict mode and silently ignored in lenient mode).
> > > > >
> > > > > I can understand that it does not match the precision of your logic
> > >
> > > based
> > >
> > > > > on
> > > > > todays code: did you look at Maven 2 code? did you look at every
> other
> > > > > consumer of Maven Central content?
> > > > >
> > > > > whatever you feel about it today, that's what has been defined and
> > > > > done
> > > > > for now
> > > > > more than 15 years, and proven working, and AFAIK checked when
> > >
> > > publishing
> > >
> > > > > to
> > > > > Maven Central
> > > > >
> > > > > If we change that, we are changing the Maven Central contract for
> > > > > everybody
> > > > > from the past and future
> > > > >
> > > > > Maven 5 is not only about Maven: it's also about Maven Central,
> which
> > >
> > > is
> > >
> > > > > the
> > > > > hardest piece to make sure we don't break usage
> > > > >
> > > > > Regards,
> > > > >
> > > > > Hervé
> > > > >
> > > > >
> > > > >
> > > > >
> ---------------------------------------------------------------------
> > > > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > > > > For additional commands, e-mail: dev-help@maven.apache.org
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > > For additional commands, e-mail: dev-help@maven.apache.org
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
--
------------------------
Guillaume Nodet
Re: [DISCUSS] POM model version
Posted by Hervé Boutemy <he...@free.fr>.
I now understand our divergence: you implicitely use Maven 4 with some updates
already done on xsd versions that I did not know about, and I don't yet
understand what has already be done on build vs consumer POM transformation
First, having some feedback from people on the idea of using plugin execution
priority would be useful, because even before diving into implementation
details, this approach is to be accepted.
If devs agree on the introduction of basic priority, we have 3 ways to
implement its introduction:
1. Maven 3 way = add as an XML attribute: <element priority="100">
Fully compatible with current Maven Central conventions, no need to change
anything
done in https://github.com/apache/maven/pull/1173
as you can see, it's a modification of 2 lines + some documentation
tested with a sample project:
https://github.com/hboutemy/MNG-7804-plugin-execution-priority
2. the Maven 5 way: add a new XML element, and manage the fact that it will
change all the expectations from a Maven Central perspective
= what we were supposed to do in the future, once people have some experience
with Maven 4 and build vs consumer POM, plus all what is required to be added
as constraints at maven Central level
3. the Maven 4 way: here, I still don't get what has been already done on POM
xmlns, POM xsd, and what is published to Maven Central
But clearly, it already opens many questions to be seriously understood on
build vs consumer POM and how this new field goes (or not) to Maven Central in
a compatible way. Maven 4 was not supposed to change anything at Maven Central
level.
option 2 or 3 give me headaches
The PR remains small https://github.com/apache/maven/pull/1147
but it is clearly defining many new ways of handling POM evolution both
internally (build vs consumer) and externally for Maven Central
if one of these is chosen, I ask everybody to seriously work on it and
document all the new aspects that this reveals
Don't just say "nice"
Regards,
Hervé
Le samedi 17 juin 2023, 10:07:42 CEST Guillaume Nodet a écrit :
> Le ven. 16 juin 2023, 19:20, Hervé Boutemy <he...@free.fr> a écrit :
> > Le mercredi 14 juin 2023, 10:07:46 CEST Guillaume Nodet a écrit :
> > > I think this is exactly what Hervé explains was rejected years ago. The
> > > assumption is that the POM v4 is "set in amber" and will never change,
> > > at
> > > least for the consumer side, i.e. defining dependencies. For the build
> > > side, it has to evolve, so the POM v5 will need a different schema url
> > > or
> > >
> > > version. But imho the goals are:
> > > * make sure we keep POM v4 the way it is to tools for consumers
> > > * allow some room for POM v5 on the build side
> > >
> > > However, the problem I see is that when you deploy a "pom" package, i.e.
> >
> > a
> >
> > > parent POM that may be used as a parent for other projects, we clearly
> >
> > have
> >
> > > a problem for which I do not really have a clear understanding how to
> > > solve. Let's assume this POM uses a POM v5 new feature, so that the
> > > semantic data carried by this POM can not be written with a POM v4.
> >
> > Such a
> >
> > > POM can not be uploaded to maven central in the v4 form, so it WILL
> > > break
> > > tools, but I don't really see any other way.
> > >
> > > So here's what I propose:
> > > * further trim down the consumer POM as it was envisioned years ago in
> > >
> > > [1] and [2] (the removed data will still be available for other tools to
> > > consume, see below)
> > >
> > > * we want to relax the constraints of the v4 pom schema a bit to be
> >
> > able
> >
> > > to validate the current build pom (where a few things are inferred)
> > >
> > > * for packaged artifacts, we will upload the consumer POM v4 as the
> >
> > main
> >
> > > POM and the normalized POM v4/v5 as an attached artifact
> > >
> > > * for the "pom" package, we will upload the normalized POM v4/v5 as
> > > the
> > >
> > > main POM (no consumer POM)
> > >
> > > In the short term we could then:
> > > * allow the definition of POM v4.x, i.e. small evolutions with a
> > > schema
> > >
> > > compatible to v4 (i.e. mostly new elements / attributes) that will give
> > > a
> > > bit of freedom to implement new stuff (i.e. we should start properly
> > > versioning it and communicate to the community that they will have to
> >
> > adapt
> >
> > > their tools)
> > >
> > > * when deploying the v4/v5 POM as the main POM (i.e. for pom
> > > packages),
> > >
> > > we could be smart enough to see if the POM requires non v4 features and
> >
> > if
> >
> > > that's not the case, upload it as a the lower version possible (i.e. POM
> > > v4), thereby minimizing disruption for other tools scanning central (and
> > > allow consumption with maven 3.x)
> > >
> > > Longer term:
> > > * define a POM v5+ schema (with GAV as attributes, etc...)
> > >
> > > Thoughts ?
> >
> > ok for new attributes, that can simply added in POM v4.2
> >
> > not ok for new elements: new elements are POM v5, with all the subtle
> > choices
> > to be done that you listed but I still did not have time to properly
> > evaluate,
> > and all the people who should really take time to evaluate. Notably those
> > who
> > will have to adapt publication rules to Maven Central for POM v5.
>
> Well, v4.2 or V5, it's just a number. The point is that the url of the
> schema changes, so it's a new namespace. What is important is what we put
> behind this number. What I'd like to come up with is a policy for defining
> changes in the model. I don't think it would be a good idea to release a
> new POM version and keep it in amber forever as that was the case for
> 4.0.0. Given we would have a consumer POM set in amber, the goal is to
> have more freedom for the normalized POM that will be uploaded when
> deploying parents.
>
> Also, one thing to consider, is the use of alternatives syntax/language for
> the POM on the file system. If we want to minimize disruptions, we could
> choose to translate the POM on the file system to the normalized POM in a
> schema which would be compatible with the current schema. That's what
> polyglot has implemented and we could borrow the idea (as I demonstrated
> with the HOCON parser).
>
> So we'd have:
> * the amber'd POM 4.0.0 for consumer/flattened POMs (all packaged
> artifacts and BOMs)
> * the normalized new POM for deployed parent POMs (whatever version we
> want to give to it)
> * the build POM on the file system for which we could define alternative
> syntax
>
> Guillaume
>
> > Regards,
> >
> > Hervé
> >
> > > Guillaume
> > >
> > > [1] https://maven.apache.org/studies/consumer-pom/maven.html
> > > [2]
> >
> > https://cwiki.apache.org/confluence/display/MAVEN/Build+vs+Consumer+POM
> >
> > > Le mer. 14 juin 2023 à 08:48, Hunter C Payne
> > >
> > > <hu...@yahoo.com.invalid> a écrit :
> > > > Sorry for chiming in again but perhaps I might have an idea. The XSD
> > > >
> > > > schema that a POM uses is actually referenced from the POM. So in
> >
> > essence
> >
> > > > each POM carries with it what is needed to know to parse it. Perhaps
> >
> > in
> >
> > > > Maven 5 (or whichever version) we can require POM parsers to read and
> >
> > use
> >
> > > > the specific XSD schema referenced in the POM. That way you can have
> >
> > more
> >
> > > > room to try changes to the POM format. But there really should be a
> > > > mechanism for pushing POM changes downstream and XSD seems like a good
> > > > option for that. Sorry if this is already the plan and I'm repeating
> >
> > what
> >
> > > > is already known.
> > > >
> > > > Hunter
> > > >
> > > > On Tuesday, June 13, 2023 at 11:12:39 PM PDT, Hervé Boutemy <
> > > >
> > > > herve.boutemy@free.fr> wrote:
> > > > Le lundi 12 juin 2023, 01:50:56 CEST Guillaume Nodet a écrit :
> > > > > > 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).
> > > > >
> > > > > I can't buy that argument. You're saying that we should not assume
> >
> > the
> >
> > > > way
> > > >
> > > > > the POM is parsed, but we assume they don't parse arguments. That's
> > > > > clearly dodgy, and false for our own parser (both are parsed and
> > > > > rejected
> > > > > in strict mode and silently ignored in lenient mode).
> > > >
> > > > I can understand that it does not match the precision of your logic
> >
> > based
> >
> > > > on
> > > > todays code: did you look at Maven 2 code? did you look at every other
> > > > consumer of Maven Central content?
> > > >
> > > > whatever you feel about it today, that's what has been defined and
> > > > done
> > > > for now
> > > > more than 15 years, and proven working, and AFAIK checked when
> >
> > publishing
> >
> > > > to
> > > > Maven Central
> > > >
> > > > If we change that, we are changing the Maven Central contract for
> > > > everybody
> > > > from the past and future
> > > >
> > > > Maven 5 is not only about Maven: it's also about Maven Central, which
> >
> > is
> >
> > > > the
> > > > hardest piece to make sure we don't break usage
> > > >
> > > > Regards,
> > > >
> > > > Hervé
> > > >
> > > >
> > > >
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > > > For additional commands, e-mail: dev-help@maven.apache.org
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [DISCUSS] POM model version
Posted by Guillaume Nodet <gn...@apache.org>.
Le ven. 16 juin 2023, 19:20, Hervé Boutemy <he...@free.fr> a écrit :
> Le mercredi 14 juin 2023, 10:07:46 CEST Guillaume Nodet a écrit :
> > I think this is exactly what Hervé explains was rejected years ago. The
> > assumption is that the POM v4 is "set in amber" and will never change, at
> > least for the consumer side, i.e. defining dependencies. For the build
> > side, it has to evolve, so the POM v5 will need a different schema url or
> > version. But imho the goals are:
> > * make sure we keep POM v4 the way it is to tools for consumers
> > * allow some room for POM v5 on the build side
> >
> > However, the problem I see is that when you deploy a "pom" package, i.e.
> a
> > parent POM that may be used as a parent for other projects, we clearly
> have
> > a problem for which I do not really have a clear understanding how to
> > solve. Let's assume this POM uses a POM v5 new feature, so that the
> > semantic data carried by this POM can not be written with a POM v4.
> Such a
> > POM can not be uploaded to maven central in the v4 form, so it WILL break
> > tools, but I don't really see any other way.
> >
> > So here's what I propose:
> > * further trim down the consumer POM as it was envisioned years ago in
> > [1] and [2] (the removed data will still be available for other tools to
> > consume, see below)
> > * we want to relax the constraints of the v4 pom schema a bit to be
> able
> > to validate the current build pom (where a few things are inferred)
> > * for packaged artifacts, we will upload the consumer POM v4 as the
> main
> > POM and the normalized POM v4/v5 as an attached artifact
> > * for the "pom" package, we will upload the normalized POM v4/v5 as the
> > main POM (no consumer POM)
> >
> > In the short term we could then:
> > * allow the definition of POM v4.x, i.e. small evolutions with a schema
> > compatible to v4 (i.e. mostly new elements / attributes) that will give a
> > bit of freedom to implement new stuff (i.e. we should start properly
> > versioning it and communicate to the community that they will have to
> adapt
> > their tools)
> > * when deploying the v4/v5 POM as the main POM (i.e. for pom packages),
> > we could be smart enough to see if the POM requires non v4 features and
> if
> > that's not the case, upload it as a the lower version possible (i.e. POM
> > v4), thereby minimizing disruption for other tools scanning central (and
> > allow consumption with maven 3.x)
> > Longer term:
> > * define a POM v5+ schema (with GAV as attributes, etc...)
> >
> > Thoughts ?
> ok for new attributes, that can simply added in POM v4.2
>
> not ok for new elements: new elements are POM v5, with all the subtle
> choices
> to be done that you listed but I still did not have time to properly
> evaluate,
> and all the people who should really take time to evaluate. Notably those
> who
> will have to adapt publication rules to Maven Central for POM v5.
>
Well, v4.2 or V5, it's just a number. The point is that the url of the
schema changes, so it's a new namespace. What is important is what we put
behind this number. What I'd like to come up with is a policy for defining
changes in the model. I don't think it would be a good idea to release a
new POM version and keep it in amber forever as that was the case for
4.0.0. Given we would have a consumer POM set in amber, the goal is to
have more freedom for the normalized POM that will be uploaded when
deploying parents.
Also, one thing to consider, is the use of alternatives syntax/language for
the POM on the file system. If we want to minimize disruptions, we could
choose to translate the POM on the file system to the normalized POM in a
schema which would be compatible with the current schema. That's what
polyglot has implemented and we could borrow the idea (as I demonstrated
with the HOCON parser).
So we'd have:
* the amber'd POM 4.0.0 for consumer/flattened POMs (all packaged
artifacts and BOMs)
* the normalized new POM for deployed parent POMs (whatever version we
want to give to it)
* the build POM on the file system for which we could define alternative
syntax
Guillaume
> Regards,
>
> Hervé
>
> >
> > Guillaume
> >
> > [1] https://maven.apache.org/studies/consumer-pom/maven.html
> > [2]
> https://cwiki.apache.org/confluence/display/MAVEN/Build+vs+Consumer+POM
> >
> > Le mer. 14 juin 2023 à 08:48, Hunter C Payne
> >
> > <hu...@yahoo.com.invalid> a écrit :
> > > Sorry for chiming in again but perhaps I might have an idea. The XSD
> > >
> > > schema that a POM uses is actually referenced from the POM. So in
> essence
> > > each POM carries with it what is needed to know to parse it. Perhaps
> in
> > > Maven 5 (or whichever version) we can require POM parsers to read and
> use
> > > the specific XSD schema referenced in the POM. That way you can have
> more
> > > room to try changes to the POM format. But there really should be a
> > > mechanism for pushing POM changes downstream and XSD seems like a good
> > > option for that. Sorry if this is already the plan and I'm repeating
> what
> > > is already known.
> > >
> > > Hunter
> > >
> > > On Tuesday, June 13, 2023 at 11:12:39 PM PDT, Hervé Boutemy <
> > >
> > > herve.boutemy@free.fr> wrote:
> > > Le lundi 12 juin 2023, 01:50:56 CEST Guillaume Nodet a écrit :
> > > > > 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).
> > > >
> > > > I can't buy that argument. You're saying that we should not assume
> the
> > >
> > > way
> > >
> > > > the POM is parsed, but we assume they don't parse arguments. That's
> > > > clearly dodgy, and false for our own parser (both are parsed and
> > > > rejected
> > > > in strict mode and silently ignored in lenient mode).
> > >
> > > I can understand that it does not match the precision of your logic
> based
> > > on
> > > todays code: did you look at Maven 2 code? did you look at every other
> > > consumer of Maven Central content?
> > >
> > > whatever you feel about it today, that's what has been defined and done
> > > for now
> > > more than 15 years, and proven working, and AFAIK checked when
> publishing
> > > to
> > > Maven Central
> > >
> > > If we change that, we are changing the Maven Central contract for
> > > everybody
> > > from the past and future
> > >
> > > Maven 5 is not only about Maven: it's also about Maven Central, which
> is
> > > the
> > > hardest piece to make sure we don't break usage
> > >
> > > Regards,
> > >
> > > Hervé
> > >
> > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > > For additional commands, e-mail: dev-help@maven.apache.org
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
Re: [DISCUSS] POM model version
Posted by Hervé Boutemy <he...@free.fr>.
Le mercredi 14 juin 2023, 10:07:46 CEST Guillaume Nodet a écrit :
> I think this is exactly what Hervé explains was rejected years ago. The
> assumption is that the POM v4 is "set in amber" and will never change, at
> least for the consumer side, i.e. defining dependencies. For the build
> side, it has to evolve, so the POM v5 will need a different schema url or
> version. But imho the goals are:
> * make sure we keep POM v4 the way it is to tools for consumers
> * allow some room for POM v5 on the build side
>
> However, the problem I see is that when you deploy a "pom" package, i.e. a
> parent POM that may be used as a parent for other projects, we clearly have
> a problem for which I do not really have a clear understanding how to
> solve. Let's assume this POM uses a POM v5 new feature, so that the
> semantic data carried by this POM can not be written with a POM v4. Such a
> POM can not be uploaded to maven central in the v4 form, so it WILL break
> tools, but I don't really see any other way.
>
> So here's what I propose:
> * further trim down the consumer POM as it was envisioned years ago in
> [1] and [2] (the removed data will still be available for other tools to
> consume, see below)
> * we want to relax the constraints of the v4 pom schema a bit to be able
> to validate the current build pom (where a few things are inferred)
> * for packaged artifacts, we will upload the consumer POM v4 as the main
> POM and the normalized POM v4/v5 as an attached artifact
> * for the "pom" package, we will upload the normalized POM v4/v5 as the
> main POM (no consumer POM)
>
> In the short term we could then:
> * allow the definition of POM v4.x, i.e. small evolutions with a schema
> compatible to v4 (i.e. mostly new elements / attributes) that will give a
> bit of freedom to implement new stuff (i.e. we should start properly
> versioning it and communicate to the community that they will have to adapt
> their tools)
> * when deploying the v4/v5 POM as the main POM (i.e. for pom packages),
> we could be smart enough to see if the POM requires non v4 features and if
> that's not the case, upload it as a the lower version possible (i.e. POM
> v4), thereby minimizing disruption for other tools scanning central (and
> allow consumption with maven 3.x)
> Longer term:
> * define a POM v5+ schema (with GAV as attributes, etc...)
>
> Thoughts ?
ok for new attributes, that can simply added in POM v4.2
not ok for new elements: new elements are POM v5, with all the subtle choices
to be done that you listed but I still did not have time to properly evaluate,
and all the people who should really take time to evaluate. Notably those who
will have to adapt publication rules to Maven Central for POM v5.
Regards,
Hervé
>
> Guillaume
>
> [1] https://maven.apache.org/studies/consumer-pom/maven.html
> [2] https://cwiki.apache.org/confluence/display/MAVEN/Build+vs+Consumer+POM
>
> Le mer. 14 juin 2023 à 08:48, Hunter C Payne
>
> <hu...@yahoo.com.invalid> a écrit :
> > Sorry for chiming in again but perhaps I might have an idea. The XSD
> >
> > schema that a POM uses is actually referenced from the POM. So in essence
> > each POM carries with it what is needed to know to parse it. Perhaps in
> > Maven 5 (or whichever version) we can require POM parsers to read and use
> > the specific XSD schema referenced in the POM. That way you can have more
> > room to try changes to the POM format. But there really should be a
> > mechanism for pushing POM changes downstream and XSD seems like a good
> > option for that. Sorry if this is already the plan and I'm repeating what
> > is already known.
> >
> > Hunter
> >
> > On Tuesday, June 13, 2023 at 11:12:39 PM PDT, Hervé Boutemy <
> >
> > herve.boutemy@free.fr> wrote:
> > Le lundi 12 juin 2023, 01:50:56 CEST Guillaume Nodet a écrit :
> > > > 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).
> > >
> > > I can't buy that argument. You're saying that we should not assume the
> >
> > way
> >
> > > the POM is parsed, but we assume they don't parse arguments. That's
> > > clearly dodgy, and false for our own parser (both are parsed and
> > > rejected
> > > in strict mode and silently ignored in lenient mode).
> >
> > I can understand that it does not match the precision of your logic based
> > on
> > todays code: did you look at Maven 2 code? did you look at every other
> > consumer of Maven Central content?
> >
> > whatever you feel about it today, that's what has been defined and done
> > for now
> > more than 15 years, and proven working, and AFAIK checked when publishing
> > to
> > Maven Central
> >
> > If we change that, we are changing the Maven Central contract for
> > everybody
> > from the past and future
> >
> > Maven 5 is not only about Maven: it's also about Maven Central, which is
> > the
> > hardest piece to make sure we don't break usage
> >
> > Regards,
> >
> > Hervé
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [DISCUSS] POM model version
Posted by Guillaume Nodet <gn...@apache.org>.
Le mer. 14 juin 2023 à 10:07, Guillaume Nodet <gn...@apache.org> a écrit :
> I think this is exactly what Hervé explains was rejected years ago. The
> assumption is that the POM v4 is "set in amber" and will never change, at
> least for the consumer side, i.e. defining dependencies. For the build
> side, it has to evolve, so the POM v5 will need a different schema url or
> version. But imho the goals are:
> * make sure we keep POM v4 the way it is to tools for consumers
> * allow some room for POM v5 on the build side
>
> However, the problem I see is that when you deploy a "pom" package, i.e. a
> parent POM that may be used as a parent for other projects, we clearly have
> a problem for which I do not really have a clear understanding how to
> solve. Let's assume this POM uses a POM v5 new feature, so that the
> semantic data carried by this POM can not be written with a POM v4. Such a
> POM can not be uploaded to maven central in the v4 form, so it WILL break
> tools, but I don't really see any other way.
>
> So here's what I propose:
> * further trim down the consumer POM as it was envisioned years ago in
> [1] and [2] (the removed data will still be available for other tools to
> consume, see below)
> * we want to relax the constraints of the v4 pom schema a bit to be able
> to validate the current build pom (where a few things are inferred)
>
Actually, the schema is already relaxed wrt to required elements. It's my
IDE which must be doing additional validation because the schema looks good.
* for packaged artifacts, we will upload the consumer POM v4 as the main
> POM and the normalized POM v4/v5 as an attached artifact
> * for the "pom" package, we will upload the normalized POM v4/v5 as the
> main POM (no consumer POM)
>
Note that this would be problematic for BOM, which are pom but not used as
parents. I wonder if we should clean-up this use case by using a specific
"bom" packaging. This could also affect how the POM is transformed to a
consumer-side BOM, as we could remove the dependencyManagement element from
consumer packaged artifacts, but we'd need to keep it for consumer BOMs.
>
> In the short term we could then:
> * allow the definition of POM v4.x, i.e. small evolutions with a schema
> compatible to v4 (i.e. mostly new elements / attributes) that will give a
> bit of freedom to implement new stuff (i.e. we should start properly
> versioning it and communicate to the community that they will have to adapt
> their tools)
> * when deploying the v4/v5 POM as the main POM (i.e. for pom packages),
> we could be smart enough to see if the POM requires non v4 features and if
> that's not the case, upload it as a the lower version possible (i.e. POM
> v4), thereby minimizing disruption for other tools scanning central (and
> allow consumption with maven 3.x)
> Longer term:
> * define a POM v5+ schema (with GAV as attributes, etc...)
>
> Thoughts ?
>
> Guillaume
>
> [1] https://maven.apache.org/studies/consumer-pom/maven.html
> [2]
> https://cwiki.apache.org/confluence/display/MAVEN/Build+vs+Consumer+POM
>
> Le mer. 14 juin 2023 à 08:48, Hunter C Payne
> <hu...@yahoo.com.invalid> a écrit :
>
>> Sorry for chiming in again but perhaps I might have an idea. The XSD
>> schema that a POM uses is actually referenced from the POM. So in essence
>> each POM carries with it what is needed to know to parse it. Perhaps in
>> Maven 5 (or whichever version) we can require POM parsers to read and use
>> the specific XSD schema referenced in the POM. That way you can have more
>> room to try changes to the POM format. But there really should be a
>> mechanism for pushing POM changes downstream and XSD seems like a good
>> option for that. Sorry if this is already the plan and I'm repeating what
>> is already known.
>>
>> Hunter
>>
>> On Tuesday, June 13, 2023 at 11:12:39 PM PDT, Hervé Boutemy <
>> herve.boutemy@free.fr> wrote:
>>
>> Le lundi 12 juin 2023, 01:50:56 CEST Guillaume Nodet a écrit :
>> > > 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).
>> >
>> > I can't buy that argument. You're saying that we should not assume the
>> way
>> > the POM is parsed, but we assume they don't parse arguments. That's
>> > clearly dodgy, and false for our own parser (both are parsed and
>> rejected
>> > in strict mode and silently ignored in lenient mode).
>>
>> I can understand that it does not match the precision of your logic based
>> on
>> todays code: did you look at Maven 2 code? did you look at every other
>> consumer of Maven Central content?
>>
>> whatever you feel about it today, that's what has been defined and done
>> for now
>> more than 15 years, and proven working, and AFAIK checked when publishing
>> to
>> Maven Central
>>
>> If we change that, we are changing the Maven Central contract for
>> everybody
>> from the past and future
>>
>> Maven 5 is not only about Maven: it's also about Maven Central, which is
>> the
>> hardest piece to make sure we don't break usage
>>
>> Regards,
>>
>> Hervé
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>>
>
>
>
> --
> ------------------------
> Guillaume Nodet
>
>
--
------------------------
Guillaume Nodet
Re: [DISCUSS] POM model version
Posted by Guillaume Nodet <gn...@apache.org>.
I think this is exactly what Hervé explains was rejected years ago. The
assumption is that the POM v4 is "set in amber" and will never change, at
least for the consumer side, i.e. defining dependencies. For the build
side, it has to evolve, so the POM v5 will need a different schema url or
version. But imho the goals are:
* make sure we keep POM v4 the way it is to tools for consumers
* allow some room for POM v5 on the build side
However, the problem I see is that when you deploy a "pom" package, i.e. a
parent POM that may be used as a parent for other projects, we clearly have
a problem for which I do not really have a clear understanding how to
solve. Let's assume this POM uses a POM v5 new feature, so that the
semantic data carried by this POM can not be written with a POM v4. Such a
POM can not be uploaded to maven central in the v4 form, so it WILL break
tools, but I don't really see any other way.
So here's what I propose:
* further trim down the consumer POM as it was envisioned years ago in
[1] and [2] (the removed data will still be available for other tools to
consume, see below)
* we want to relax the constraints of the v4 pom schema a bit to be able
to validate the current build pom (where a few things are inferred)
* for packaged artifacts, we will upload the consumer POM v4 as the main
POM and the normalized POM v4/v5 as an attached artifact
* for the "pom" package, we will upload the normalized POM v4/v5 as the
main POM (no consumer POM)
In the short term we could then:
* allow the definition of POM v4.x, i.e. small evolutions with a schema
compatible to v4 (i.e. mostly new elements / attributes) that will give a
bit of freedom to implement new stuff (i.e. we should start properly
versioning it and communicate to the community that they will have to adapt
their tools)
* when deploying the v4/v5 POM as the main POM (i.e. for pom packages),
we could be smart enough to see if the POM requires non v4 features and if
that's not the case, upload it as a the lower version possible (i.e. POM
v4), thereby minimizing disruption for other tools scanning central (and
allow consumption with maven 3.x)
Longer term:
* define a POM v5+ schema (with GAV as attributes, etc...)
Thoughts ?
Guillaume
[1] https://maven.apache.org/studies/consumer-pom/maven.html
[2] https://cwiki.apache.org/confluence/display/MAVEN/Build+vs+Consumer+POM
Le mer. 14 juin 2023 à 08:48, Hunter C Payne
<hu...@yahoo.com.invalid> a écrit :
> Sorry for chiming in again but perhaps I might have an idea. The XSD
> schema that a POM uses is actually referenced from the POM. So in essence
> each POM carries with it what is needed to know to parse it. Perhaps in
> Maven 5 (or whichever version) we can require POM parsers to read and use
> the specific XSD schema referenced in the POM. That way you can have more
> room to try changes to the POM format. But there really should be a
> mechanism for pushing POM changes downstream and XSD seems like a good
> option for that. Sorry if this is already the plan and I'm repeating what
> is already known.
>
> Hunter
>
> On Tuesday, June 13, 2023 at 11:12:39 PM PDT, Hervé Boutemy <
> herve.boutemy@free.fr> wrote:
>
> Le lundi 12 juin 2023, 01:50:56 CEST Guillaume Nodet a écrit :
> > > 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).
> >
> > I can't buy that argument. You're saying that we should not assume the
> way
> > the POM is parsed, but we assume they don't parse arguments. That's
> > clearly dodgy, and false for our own parser (both are parsed and rejected
> > in strict mode and silently ignored in lenient mode).
>
> I can understand that it does not match the precision of your logic based
> on
> todays code: did you look at Maven 2 code? did you look at every other
> consumer of Maven Central content?
>
> whatever you feel about it today, that's what has been defined and done
> for now
> more than 15 years, and proven working, and AFAIK checked when publishing
> to
> Maven Central
>
> If we change that, we are changing the Maven Central contract for
> everybody
> from the past and future
>
> Maven 5 is not only about Maven: it's also about Maven Central, which is
> the
> hardest piece to make sure we don't break usage
>
> Regards,
>
> Hervé
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
--
------------------------
Guillaume Nodet
Re: [DISCUSS] POM model version
Posted by Hunter C Payne <hu...@yahoo.com.INVALID>.
Sorry for chiming in again but perhaps I might have an idea. The XSD schema that a POM uses is actually referenced from the POM. So in essence each POM carries with it what is needed to know to parse it. Perhaps in Maven 5 (or whichever version) we can require POM parsers to read and use the specific XSD schema referenced in the POM. That way you can have more room to try changes to the POM format. But there really should be a mechanism for pushing POM changes downstream and XSD seems like a good option for that. Sorry if this is already the plan and I'm repeating what is already known.
Hunter
On Tuesday, June 13, 2023 at 11:12:39 PM PDT, Hervé Boutemy <he...@free.fr> wrote:
Le lundi 12 juin 2023, 01:50:56 CEST Guillaume Nodet a écrit :
> > 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).
>
> I can't buy that argument. You're saying that we should not assume the way
> the POM is parsed, but we assume they don't parse arguments. That's
> clearly dodgy, and false for our own parser (both are parsed and rejected
> in strict mode and silently ignored in lenient mode).
I can understand that it does not match the precision of your logic based on
todays code: did you look at Maven 2 code? did you look at every other
consumer of Maven Central content?
whatever you feel about it today, that's what has been defined and done for now
more than 15 years, and proven working, and AFAIK checked when publishing to
Maven Central
If we change that, we are changing the Maven Central contract for everybody
from the past and future
Maven 5 is not only about Maven: it's also about Maven Central, which is the
hardest piece to make sure we don't break usage
Regards,
Hervé
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [DISCUSS] POM model version
Posted by Hervé Boutemy <he...@free.fr>.
Le lundi 12 juin 2023, 01:50:56 CEST Guillaume Nodet a écrit :
> > 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).
>
> I can't buy that argument. You're saying that we should not assume the way
> the POM is parsed, but we assume they don't parse arguments. That's
> clearly dodgy, and false for our own parser (both are parsed and rejected
> in strict mode and silently ignored in lenient mode).
I can understand that it does not match the precision of your logic based on
todays code: did you look at Maven 2 code? did you look at every other
consumer of Maven Central content?
whatever you feel about it today, that's what has been defined and done for now
more than 15 years, and proven working, and AFAIK checked when publishing to
Maven Central
If we change that, we are changing the Maven Central contract for everybody
from the past and future
Maven 5 is not only about Maven: it's also about Maven Central, which is the
hardest piece to make sure we don't break usage
Regards,
Hervé
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [DISCUSS] POM model version
Posted by Guillaume Nodet <gn...@apache.org>.
Le dim. 11 juin 2023 à 23:54, Hervé Boutemy <he...@free.fr> a
écrit :
> Le vendredi 9 juin 2023, 11:22:26 CEST Guillaume Nodet a écrit :
> > Le ven. 9 juin 2023 à 08:59, Hervé Boutemy <he...@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).
>
I can't buy that argument. You're saying that we should not assume the way
the POM is parsed, but we assume they don't parse arguments. That's
clearly dodgy, and false for our own parser (both are parsed and rejected
in strict mode and silently ignored in lenient mode).
>
> > 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, ...
>
I'd prefer iterations that we can ship in a timely manner... My
understanding is that "maven 5" was to align on a new major version of the
model which is currently "4.0.0". I don't care about naming at this
point. If the point is really the above, we could skip maven 4 as it has
been written or use a new schema (see below).
>
> > 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.
>
Yes, so we'd better remove them before uploading then. That's what allows
the build/consumer pom.
>
> >
> > 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
>
Why not, but it's currently broken because we don't have a proper schema to
validate the build pom. And I don't really think that's a good idea. We
can either cheat a bit again and relax the current schema, or start using a
new schema, as I indicated in my other email. And if it's really about the
naming, I proposed http://maven.apache.org/BUILD/4.0.0 which would keep
things even more aligned, as everything would be 4.0.0 !
> 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-unsubscribe@maven.apache.org
> > > For additional commands, e-mail: dev-help@maven.apache.org
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
--
------------------------
Guillaume Nodet
Re: [DISCUSS] POM model version
Posted by Hervé Boutemy <he...@free.fr>.
Le vendredi 9 juin 2023, 11:22:26 CEST Guillaume Nodet a écrit :
> Le ven. 9 juin 2023 à 08:59, Hervé Boutemy <he...@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-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [DISCUSS] POM model version
Posted by Guillaume Nodet <gn...@apache.org>.
Le ven. 9 juin 2023 à 08:59, Hervé Boutemy <he...@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.
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 !
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 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.
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).
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-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
--
------------------------
Guillaume Nodet
Re: [DISCUSS] POM model version
Posted by Romain Manni-Bucau <rm...@gmail.com>.
+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 <he...@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-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
Re: [DISCUSS] POM model version
Posted by Hervé Boutemy <he...@free.fr>.
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-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [DISCUSS] POM model version
Posted by Olivier Lamy <ol...@apache.org>.
On Fri, 9 Jun 2023 at 16:23, Heiko Studt <he...@iteg.at> wrote:
>
> Hallo,
>
> Quote:
> > the pom with a hardcoded version of the schema.
> > But frankly let's consider this as a bug in the tool/ide doing so.
>
> Sorry to disagree: from a security standpoint, XSD is sufficient complex
> enough that I do not want to download one from a random location on the
> internet, especially if this means to remove hard constraints on what
> will be parsed by the second stage (after validation) within my tool or
> within mvn.
is this really a random location
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
https://maven.apache.org/maven-v4_0_0.xsd" ?
As long as the tool use this what is the problem to validate them
against something such
xsi:schemaLocation="http://maven.apache.org/POM/4.2.0
https://maven.apache.org/maven-v4_2_0.xsd"
>
> I have had some experience with utilizing XSD for generating tools to
> consume and some backwards compatibility issues. Whether the consumer
> will work dependends *a lot* on the features of XSD you are using and
> whether those changes are *truely* compatible with the (generated!)
> parser for a specific language.
> There are quite a few legacy parsers out...
>
> For example, in XSD the "sequence" has a misleading name, because you
> cannot introduce any elements in-between or fail (only) the backwards
> compatibility, while everything will work inside the new-version-using
> ecosystem.
> The problem arises only on sequence mempers *after* the one introduced
> and shows itself by not transfering these "extra" old ones into the
> object. It is quite surprising to find objects without said properties,
> while the XML input had the corresponding elements set quite clearly and
> loudly...
> => Additionally, this cannot be unit-tested against efficiently, because
> you need a full compatibility matrix and it depends on the consumer tool
> which are plenty as well
>
> Another problematic one is the "enumeration" which might break your
> parser if an unknown value (from the next version) was allowed by the
> schema validation and cannot be fit into the target language code's enum
> type.
>
> However, both these features are not used in a problematic fassion in
> the current Maven POM XSD, so argueably this does not matter.
> But, perhaps these are why the fixed approach is different on adding
> attributes vs adding elements, as attributes are always non-sequential.
>
> I would suggest to put all the new XSD features onto a major version
> update, as any update into e.g. maven 4 will be seen as a compatibility
> risk anyways and therefore tested more extensively and manually after
> adoption.
>
> To why the dependencies are leniently validated instead: probably there
> are only a few features of the POM being used anyways. New elements or
> attributes, like the priority, do not need to break the dependency tree
> of the built artifact!?!
> Otherwise one library using a newer maven version as its build tool will
> break any consumer utilizing an older maven version.
>
>
> Just my 2 cent
> MfG (Kind regards)
>
> Heiko Studt
>
> Am 09.06.23 um 03:02 schrieb Olivier Lamy:
> > sounds like a new feature (MNG-7804)
> > The only problem I can imagine is with tools/ide consuming the build
> > pom if they do not respect the xmlns and schemaLocation by validating
> > the pom with a hardcoded version of the schema.
> > But frankly let's consider this as a bug in the tool/ide doing so.
> >
> >
> > On Fri, 9 Jun 2023 at 06:57, Guillaume Nodet <gn...@apache.org> wrote:
> >>
> >> 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
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
> >
>
> MFG
> --
> Heiko Studt
> Senior Software Developer
> ------------------------------------------------------------------------
> ITEG IT-Engineers GmbH | Salurner Straße 18, A-6020 Innsbruck
> FN 365826f | Handelsgericht Innsbruck | Mobiltelefon: +43 677 63983071
> Mail: heiko.studt@iteg.at | Web http://www.iteg.at/team/hstudt
> ------------------------------------------------------------------------
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [DISCUSS] POM model version
Posted by Heiko Studt <he...@iteg.at>.
Hallo,
Quote:
> the pom with a hardcoded version of the schema.
> But frankly let's consider this as a bug in the tool/ide doing so.
Sorry to disagree: from a security standpoint, XSD is sufficient complex
enough that I do not want to download one from a random location on the
internet, especially if this means to remove hard constraints on what
will be parsed by the second stage (after validation) within my tool or
within mvn.
I have had some experience with utilizing XSD for generating tools to
consume and some backwards compatibility issues. Whether the consumer
will work dependends *a lot* on the features of XSD you are using and
whether those changes are *truely* compatible with the (generated!)
parser for a specific language.
There are quite a few legacy parsers out...
For example, in XSD the "sequence" has a misleading name, because you
cannot introduce any elements in-between or fail (only) the backwards
compatibility, while everything will work inside the new-version-using
ecosystem.
The problem arises only on sequence mempers *after* the one introduced
and shows itself by not transfering these "extra" old ones into the
object. It is quite surprising to find objects without said properties,
while the XML input had the corresponding elements set quite clearly and
loudly...
=> Additionally, this cannot be unit-tested against efficiently, because
you need a full compatibility matrix and it depends on the consumer tool
which are plenty as well
Another problematic one is the "enumeration" which might break your
parser if an unknown value (from the next version) was allowed by the
schema validation and cannot be fit into the target language code's enum
type.
However, both these features are not used in a problematic fassion in
the current Maven POM XSD, so argueably this does not matter.
But, perhaps these are why the fixed approach is different on adding
attributes vs adding elements, as attributes are always non-sequential.
I would suggest to put all the new XSD features onto a major version
update, as any update into e.g. maven 4 will be seen as a compatibility
risk anyways and therefore tested more extensively and manually after
adoption.
To why the dependencies are leniently validated instead: probably there
are only a few features of the POM being used anyways. New elements or
attributes, like the priority, do not need to break the dependency tree
of the built artifact!?!
Otherwise one library using a newer maven version as its build tool will
break any consumer utilizing an older maven version.
Just my 2 cent
MfG (Kind regards)
Heiko Studt
Am 09.06.23 um 03:02 schrieb Olivier Lamy:
> sounds like a new feature (MNG-7804)
> The only problem I can imagine is with tools/ide consuming the build
> pom if they do not respect the xmlns and schemaLocation by validating
> the pom with a hardcoded version of the schema.
> But frankly let's consider this as a bug in the tool/ide doing so.
>
>
> On Fri, 9 Jun 2023 at 06:57, Guillaume Nodet <gn...@apache.org> wrote:
>>
>> 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
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
MFG
--
Heiko Studt
Senior Software Developer
------------------------------------------------------------------------
ITEG IT-Engineers GmbH | Salurner Straße 18, A-6020 Innsbruck
FN 365826f | Handelsgericht Innsbruck | Mobiltelefon: +43 677 63983071
Mail: heiko.studt@iteg.at | Web http://www.iteg.at/team/hstudt
------------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [DISCUSS] POM model version
Posted by Olivier Lamy <ol...@apache.org>.
sounds like a new feature (MNG-7804)
The only problem I can imagine is with tools/ide consuming the build
pom if they do not respect the xmlns and schemaLocation by validating
the pom with a hardcoded version of the schema.
But frankly let's consider this as a bug in the tool/ide doing so.
On Fri, 9 Jun 2023 at 06:57, Guillaume Nodet <gn...@apache.org> wrote:
>
> 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
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org