when we put "build-pom vs consumer-pom" in place, we don't need to publish build poms in the repository: the repository is here only to consume already- built artifacts as dependencies, then with their consumer pom, then without newer Maven version prerequisites (= what we want: let people consume the built artifact without constraints on their build tool)
The key feature is to be able to generate a consumer-pom with good old POM 4.0 semantics (and without build configuration, which is useless for consumers): I suppose the new "include" scope could be expanded to classical dependencies/dependencyManagement in consumer pom, for example. the only build-poms we need in central are parent poms, ie poms with pom packaging: these poms are only necessary to build the artifacts, then putting some Maven version prerequisite to use them is not an issue. Notice that consumer-poms for parent poms are not useful: then IMHO, for parent poms, only build-poms should be published to central, when for any other pom, only consumer-poms should be published. With this, we have a sustainable solution, where we have only one pom per artifactId, isn't it? The only limitation is when we can't generate a build-pom from the consumer- pom, since the new semantics has really no equivalent: is there such a case? (remember, it's about artifact consumption, not artifact build) Regards, Hervé Le lundi 22 août 2016 19:26:54 Christian Schulte a écrit : > 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, --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
