On Mon, 10 Oct 2016 11:08:52 +0200, Stephen Connolly
<stephen.alan.conno...@gmail.com> wrote:
On 10 October 2016 at 09:40, Stephen Connolly <
stephen.alan.conno...@gmail.com> wrote:
https://issues.apache.org/jira/browse/MNG-5971
I would argue that the behaviour change in MNG-5971 should not be
introduced at the same time as a refactoring to move to the new "code
formerly known as Eclipse Aether but now at Apache under a different
name"
codebase.
So, in short, I think of the 10 issues, only one "potentially" qualifies
as perhaps maybe requiring a modelVersion bump, and I would not want
that
included with the other changes for 3.4.x anyway
Reading carefully through this issue I am inclined to lean towards
Stéphane's opinion that it is more of a bug fix than an RFE that has been
reported. That does not mean that the suggested implementation of the fix
is a bug fix or an RFE.
The real root problem here is that import scope was introduced without a
clear specification and there is no clear documentation on how exactly
import scope should work.
We have the principle that anything I declare in my pom wins.
After my pom, the next priority is my parent pom, followed by
grandparent,
etc.
Only after that do we start looking at things defined in dependencies
which
will win over anything defined in dependencyManagement...
Finally when resolving conflicts in dependency trees, only at that point
do
we start getting complex and consider the tree depth... which closest
winning and finally pom order being used to resolve the case where tree
depth is equal (this last one is IMHO a mistake... rather we should fail
the build if pom order is the only way to resolve a conflict as pom order
is magic to most people... at least for inheritance purposes)
ASIDE: why is pom order unclear? Well if I have a <dependencies> in my
parent and <dependencies> in my pom, which entries come first...
parent's
or child's? if the parent's then the parent wins and that breaks
things...
if the child's then that is counter-intuitive for most people... never
mind
that this important decision is not documented anywhere... oh and
help:effective-pom shows that the parent entries come first... which is
at
odds with the child being able to override the parent... so if the child
needs to change the "pom-order" of dependencies inherited from its
parent... sorry out of luck
So what would I expect from scope=import... I would expect it to be an
in-place substitution of the <dependencyManagement> from the imported pom
(modulo duplicate removal)
In the situation of a lack of specification, fixing the behaviour to work
that way would be a bug fix... a bug fix with big consequences... but
still
a bug fix within the scope of what we have called modelVersion 4.0.0
(because we added import scope without a clear specification)... it is
not
furthering the mistake of adding import scope, rather it is clarifying
the
(non-existing) specification of import scope.
I would not make such a change in 3.4.x though as it would conflate other
important changes that we need people to feel safe adopting so that we
can
start to move forward again.
But that is my opinion... and I reserve the right to disagree with my own
opinion and to change my mind mid-sentence... especially in the light of
a
better line of argument... just not seen one yet ;-)
Even if it is a bug, we know there are projects which rely on this
behavoir for a long time. And for that reason I wouldn't fix it in 3.4.0.
It would be nice if we could help projects relying on this bug by giving
them a warning during build, but I can imagine that's hard to identify.
I personally would never set or change elements in a managed dependency
which have a default value, because it can be confusing in the modules and
childs using it. But since those elements are there in the model, they can
be used. So maybe it is just my advice, and for those who want to use
them, well, they can.
Robert
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
