On Monday 22 August 2016, Christian Schulte <[email protected]> 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 > > > 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. > > > Regards, > -- > Christian > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] <javascript:;> > For additional commands, e-mail: [email protected] <javascript:;> > > -- Sent from my phone
