Hi Stephen,
On 23/08/16 01:12, Stephen Connolly wrote:
On Monday 22 August 2016, Christian Schulte <c...@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-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
