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 <[email protected]>
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=6b527ca8666c279f55047702b3987f37b032bbe3;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: [email protected]
For additional commands, e-mail: [email protected]
