On Monday 22 August 2016, Karl Heinz Marbaise <[email protected]> wrote:
> Hi Stephen, > On 23/08/16 01:12, Stephen Connolly wrote: > >> 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 >> > > 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+ I'm fine if we all agree that we start from 3.0 But I'd rather the data point first. Let's get the data point and decide from there. I suspect that everything <= 3.3.4 will blow up if encountering a modelVersion != 4.0.0 In which case your point about 2.x being EOL is moot Let's get the data points, then we can make a decision > > > 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: [email protected] > For additional commands, e-mail: [email protected] > > -- Sent from my phone
