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