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 ;-)
