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. So I am -1 on bumping a version number without an associated fix to future-proof this. I will, however, provide a *really bad solution* to this problem: XSLT We can switch to deploying only two poms (at least for the next 5-10 years say... until we have metrics showing that most consumers are modern enough) We deploy - at known maven coordinates - an XSLT stylesheet that maps each modelVersion to another modelVersion. Now any Maven 3.4.0+ client that gets a modelVersion newer than it can parse will just pull down the XSLT to transform the pom into the desired modelVersion and parse that. It needs to be XSLT so that the transformation can be used by non-JVM parsers of the pom format. The "consumer" pom will not be generated by Humans... so XML is actually a perfectly cromulent format for it... and hence XSLT is the obvious choice to convert from newer modelVersions into older modelVersions. Each Maven Version would already come with the *best in class* translation models for older versions so that you would only need to download newer ones if encountered. The builder pom would be free to evolve into whatever format we choose... can even switch to a non-xml DSL if that helps. That is my *really bad solution*. I really hope somebody can come up with a better solution to this problem as I hate this one, but it is the best I have yet. Critical requirements: * Must not assume that the program parsing the pom is running on the JVM (I have seen people parsing POMs with Ruby and JavaScript and even one or two using Erlang). Now while you can run all of these on the JVM, you do not need to, so we cannot assume that these tools are running on a JVM. This immediately rejects any solution that involves downloading a .jar file that will transform one version into another. * Must be best effort forward compatible. Where a feature can be mapped to the older model version, it should be mapped. Where a feature cannot be mapped it is OK to drop it on the floor. * We can assume the base functionality for anyone using the XSLT transformation as being the first modelVersion *after* 4.0.0... because we will be deploying the 4.0.0 poms anyway so only clients that understand the first new modelVersion will be following the XSLT transformation route. Thus the modelVersion after 4.0.0 is our one chance to get the base model as close to perfect as we can make it... any fix-up later on will need to happen by XSLT. So on that basis I think that shooting for a 4.1.0 is actually the wrong thing. We should shoot for a 5.0.0 and be done with it. The blocker from jumping to 5.0.0 has been deciding on how to handle forward compatibility to ensure that we only deploy 2 poms. If we get the 5.0.0 model right, we can even have an XSLT to down map that to 4.0.0 and detect a repository manager from HTML headers on the initial deployment and skip deploying the 4.0.0 pom. The repo managers can even use the XSLT to generate the 4.0.0 pom on the fly and then we are in a happy place where we only ever deploy and store one pom (though central will need to store both as it is not an active service due to scaling requirements) -Stephen On 21 August 2016 at 11:19, Karl Heinz Marbaise <khmarba...@gmx.de> wrote: > Hi, > > first changing the discussion to the dev list: > > On 21/08/16 14:36, Robert Scholte wrote: > >> Hi, >> >> Keep in mind that Maven is not the only tool/application using the >> pom.xml. >> Some of them probably never check the xsd or the modelVersion, so we >> need to be very carefull with this. >> If we introduce a new major modelVersion, that should probably result in >> a new file including a backported to the current 4.0.0 so all tools will >> keep working, including older versions of Maven. >> In this case 4.1.0 doesn't change the xsd but the handling of >> dependencies. I have no idea yet about the impact of such change. The >> last thing we want is that it'll destroy the Maven repository eco system. >> > > The last sentence is very important... > > So using a new POM Model version (4.1.0) and now I will deploy it to Maven > Central. This means that only Maven 3.4+ can read and handle that. Older > Maven versions will simply fail with this new version. > > Furthermore If I would like to use Model version 4.1.0 now in my project I > can't change it alone. I can not change only my project (a multi module > build) and inherit from another POM's (corporate pom) with version 4.0.0. > This will force me to change the whole inheritance hierachie chain to use > Model version 4.1.0...and forces me to create a new hierachie of corporate > pom's which are using Model Version 4.1.0 and in consequence I have to > duplicate informations/work and maintanence which I will never do > (independent of the advantages it might have)..neither other people in > particular in companies will do so...(I have strong doubts about that). > > I'm not sure about the suggestion of Christian using > release:prepare-with-pom will that not result in a situation like this: > Using the Model version 4.1.0 to handle some issue correct but deploying a > pom with Model version 4.0.0 which can't handle that? All consumers would > consume the model version 4.0.0 pom and fail in some situations ? > > > I've got a very strong impression this will not work at all...and in the > end and the longer I'm thinking about this change: > > -1 about this Change. > > We need to find a better way for those things...May be this is exactly a > sitution to control the behaviour via a feature flag to change this. So > anybody can decide to use the new (correct) behaviour or keep the old > behaviour...(which could be defined as the default). > > As a first step we could emit warnings about those wrong pom's and give > the user the hint that he could change that by using feature flag or better > to fix the wrong pom files... > > > Changing the pom format in general can only being done in the Future with > Maven 4.X may be can start working on PoC's or working on Maven 4.X to see > how this works..and see what does not work...or may be we are getting a > better impression what kind of path we could go for in particular for the > compatibility path... > > > Introducing an new `include` scope might be solution which might be > discusses more in detail... > > > Kind regards > Karl Heinz > > > >> Hervé and I plan to work on the consumer-pom, but that requires a good >> roadmap. >> First of all we need to separate the build-pom with the >> distribution-pom. They are now exactly the same, but this needs to be >> separated to be able to move forward. >> > > > On the the things we can finally > >> fix is the absence of the version in the parent in case of a multimodule >> project. >> > > So the build-pom you don't have to define the version, only the > >> relativePath unless the default value is already okay. The >> distribution-pom can replace relativePath with the actual version. >> >> Next we need to think of the consumer-pom. The idea of this file is that >> it contains only relevant transitive information. The original idea was >> about a new format for speed and and having a list of all resolved >> dependencies. This way Maven doesn't have to go to a repository for >> every artifact, since this file already has all the required >> information. >> > > > Based on some suggested changed in Aether it seems that > >> distance still matters, so maybe the dependencies should keep its tree >> structure within this consumer-pom. >> Another advantage of this is that the file already contains the fully >> resolved tree, so you don't depend on the implementation of any tool >> anymore regarding resolution rules. >> > > > >> What is important it that we must keep a pom in the repository >> understandable for all other tools. If somehow the Maven repository >> becomes useless by introducing changes to the current pom we shouldn't >> do that, but think of a new file-format being extra installed/deployed. >> > > > Robert >> >> >> On Sun, 21 Aug 2016 02:16:34 +0200, Christian Schulte <c...@schulte.it> >> wrote: >> >> Am 08/21/16 um 00:30 schrieb Mark Derricutt: >>> >>>> Christian, is there anywhere describing what changes there are/or >>>> planned >>>> in Model version 4.1.0 at all? >>>> >>> >>> Nothing is documented yet. There have never been any plans. It's more >>> about having to revert a bunch of useful things to stay backwards >>> compatible or increase the model version and be able to ship without >>> breaking backwards compatibility. Plan is to keep all information about >>> different model versions in one central place. That currently is the >>> following class. >>> >>> <https://git-wip-us.apache.org/repos/asf?p=maven.git;a=blob; >>> f=maven-model-builder/src/main/java/org/apache/maven/ >>> model/versioning/ModelVersions.java;h=6b527ca8666c279f550477 >>> 02b3987f37b032bbe3;hb=HEAD> >>> >>> >>> If you search for the usages of the 'supportsXyz' methods, you can >>> easily spot the differences without the need for documentation today. >>> Not much. I think there are quite some things that have been discussed >>> for years that should really go into 3.4 based on model version 4.1.0 >>> now. Personally I see no reason not to progress by incrementing the >>> model version. >>> >>> Maven also is about developers producing software for developers working >>> together with developers and only developers. That should really show >>> how easy things can progress and how productive things can be and not >>> the opposite. We should all focus more on this, in my opinion. >>> >> > >
