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. > 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. 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. 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] For additional commands, e-mail: [email protected]
