Hi Robert, > 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.
Are there specific tools in mind which you believe would be broken by the 4.1.0 model bump? If no one has concrete use cases, I do not think it is worthwhile to be too concerned about this. Most external tools which consume POMs do not perform complex dependency resolution outside Maven, and if they do, it is likely there are other bugs and subtleties and differences. Worth discussing only case by case IMHO. > 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. I don't understand... the point of going to model version 4.1.0 is specifically so that older versions of Maven barf on it. This is good thing, right? > 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. In general, I like the idea of a "consumer POM" intended to be easier to consume. That's what tools like the flatten-maven-plugin are trying to provide more easily, right? But I don't think model version 4.1.0 makes the Maven repository useless. At least in my use cases, I have written significant external tooling (various shell scripts, perl scripts and Java code) that consume POMs and glean info from them, and I know none of my cases will be broken by the 4.1.0 changes. Because I don't try to perform my own complete dependency resolution—it's much simpler and more robust to lean on the Maven CLI and parse the results of e.g. "mvn dependency:list" or some such. Regards, Curtis -- Curtis Rueden LOCI software architect - http://loci.wisc.edu/software On Sun, Aug 21, 2016 at 7:36 AM, Robert Scholte <rfscho...@apache.org> 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. > > 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=6b527ca8666c279f55047702b398 >> 7f37b032bbe3;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. >> >> Regards, >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > For additional commands, e-mail: users-h...@maven.apache.org > >
