Hi,
I did some research not so long ago to find out the way managed dependency
versions are resolved and ended up with a following logical lookup
algorithm:
Whichever is encountered first:
1. for each pom up the hierarchy:
a. concrete dependency
b. managed dependency
2. for each pom up the hierarchy
a. for each import
I. for each pom up the hierarchy
i. managed dependency
II. for each pom up the hierarchy
i. for each import = 2.a.
e.g.:
1. current pom's concrete dependency
2. current pom's managed dependency
3. parent concrete dependency
4. parent managed dependency
... go up the parent hierarchy chain until no more parents found...
5. first imported pom's managed dependency
6. its parent's managed dependency
... up the parent hierarchy ...
7. first imported pom's first imported pom (yea you can nest those further)
8. it's parent...
...
9. first imported pom's second imported pom
...
10. second imported pom...
...
Michal, does your change take imports nesting into account?
2016-01-02 18:07 GMT+02:00 Michael Osipov <[email protected]>:
> Am 2016-01-02 um 17:00 schrieb Michał Kowalcze:
>
>> Basically it's in https://issues.apache.org/jira/browse/MNG-5947 along
>> with
>> example POMs. Graphically - having imports in dependency management like:
>>
>> final:1.0
>>
>> + import:1.0
>>
>> + parent:3.2.1
>>
>> + commons-collections:3.2.1
>>
>> + parent:3.2.2
>>
>> + commons-collections:3.2.2
>>
>>
>>
>> Version for commons-collections is 3.2.1 due to first match.
>>
>
> Nearest match makes sense to, i.e., shortest path to a node when several
> are in the dependency tree.
>
> Michael
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [email protected]
> For additional commands, e-mail: [email protected]
>
>
--
Regards,
Anton.
