maven-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Karl Heinz Marbaise <>
Subject Re: POM Model version 4.1.0 in 3.4.0-SNAPSHOTs
Date Tue, 23 Aug 2016 04:48:06 GMT
Hi Stephen,
On 23/08/16 01:12, Stephen Connolly wrote:
> On Monday 22 August 2016, Christian Schulte <> wrote:
>> Am 08/22/16 um 09:08 schrieb Stephen Connolly:
>>> This is why I said that the v5 pom (which v4.1 is... just under a
>> different
>>> name) would have to be deployed separately with a *best effort*
>> translation
>>> down to the 4.0.0 model deployed at the standard coordinates.
>>> The problem then becomes that we are deploying now two poms for
>> everything,
>>> a 4.0.0 as .pom and a 4.1.0 as -v4.1.0.pom say (i.e. if the classifier is
>>> "v4.1.0")
>>> That in and of itself is not the end of the world... but then Maven 3.5
>>> comes along and now every time we deploy a pom we will need to deploy a
>>> 4.0.0 as foobar-1.0.pom, a 4.1.0 as foobar-1.0-v4.1.0.pom a 4.2.0 as
>>> foobar-1.0-v4.2.0.pom...
>>> eventually we will end up deploying 20 or thirty poms at the same time...
>>> just to deploy the pom.
>>> So that will not scale.
>> That won't scale. What is to note here is that the XML schema or
>> anything syntax does not change between 4.0.0 and 4.1.0. It's just that
>> Maven 3.4 performs the dependency management import differently when
>> operating on a 4.1.0 POM instead of a 4.0.0 POM.
> But what happens when maven [2.0-3.3.4) download that Pom?
> If the answer is "blow up" then I am -1

I would really ignore Maven 2 cause it End Of Life since 2 Years ago now 
and I would also only care about Maven 3+

Kind regards
Karl Heinz

>>> So I am -1 on bumping a version number without an associated fix to
>>> future-proof this.
>> We cannot postpone such things forever. Let's just find such a
>> future-proof solution please. Those endless discussions have led to
>> nowhere so far. That -1 means I need to revert the new import scope
>> behaviour. I wouldn't mind doing that but I see the minor version
>> increment in the model version by far not so problematic as others. I
>> don't know what to do else when introducing new model building
>> behaviour. I'am on that "let's just do it, it won't do any harm" road
>> here. I better not be wrong with that, of course.
>>> I will, however, provide a *really bad solution* to this problem: XSLT
>> It's not that bad. It's XML only and would make things like polyglot
>> Maven even harder but since the consumer POM is something technical -
>> not edited manually - we could just keep it XML forever. There are XML
>> parsers and XSLT processors available for nearly every programming
>> language. So XML is what makes the most sense. What is not solved that
>> way is the change in semantics because it could only be used to
>> transform different syntaxes. The changes which made me bump the model
>> version are not syntax related.
> So then the XSLT would just change the modelVersion from 4.1.0 to 4.0.0
> Anyone using the newer artifact will have to manage their dependency graph
> anyway so no loss there... But at least they can continue to consume the
> newer artifacts and then upgrade maven when they are ready.
> If there is a security issue in a dependency, I need to upgrade the
> artifact asap... Forcing me to upgrade maven with potentially far reaching
> side effects elsewhere in the build is a bad thing... I can add the newer
> dep, execlude all transitive a and manually pull in what I need... This is
> currently what I have to do anyway if I am facing the issues driving the
> change in import scope AIUI... So no loss
>> In fact, if you diff a pom-4.0.0.xml and
>> a pom-4.1.0.xml the only difference would be the value of the model
>> version element. Maven would build the effective model differently based
>> on that value. You would not need to deploy two poms for this. So to
>> summarize, we need to find a solution for handling different syntaxes
>> and a solution to handle different semantics for the same syntax.
> It's drop to the floor or propagate the bug and let the consumer fix in
> their Pom.
> The critical thing is that I can actually depend on the artifact using the
> newer modelVersion
>> If we
>> are going to bump model versions, it must be clear to everyone what
>> increment means what. Same syntax, different semantics: minor version
>> increment. Different syntax, same semantics: major version increment.
>> Leaves the patch version for bug fixes (like changing the order of
>> elements for the combine.children attribute). Quite XML related. So we
>> better not think about the model in terms of XML. What we currently have
>> on master (4.1.0) would just work. I am not sure this model version
>> increment without any change in syntax is really such an issue, however.

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message