maven-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Karl Heinz Marbaise <khmarba...@gmx.de>
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 <cs@schulte.it> 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: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org


Mime
View raw message