Am 07/15/16 um 19:52 schrieb Robert Scholte: > I think you're right. The main issue here is c:1 is the first closest one, > but since the c:2 has compile scope, so should c:1. However, that doesn't > change the scope for transitive dependencies of c:1 > > A bit off-topic: Where is this scope order specified? In case of custom > scopes we probably need to do something with scope-order too.
I have no idea. All I have found is the source code [1]. If someone knows, please help. We have a 'JavaScopeSelector' applying a prioritization based on something "widest scope" which has nothing to do with anything nearest wins, a 'NearestVersionSelector' which does not always select the nearest version and has nothing to do with anything nearest wins, a 'SimpleOptionalitySelector' which has nothing to do with nearest wins. We have always said that Maven is applying a "nearest wins" strategy when resolving conflicts. That only applies to version hints. Hard version requirements, scopes, optionality are implemented very differently. I do not even quite understand why the scope of 'c' needs to be updated to compile. If we say nearest wins, then the scope of 'c' should be runtime. So that users need to pull up dependencies in question manually (to get correct POM files). There is quite a lot going on during conflict resolution which has nothing to do with anything nearest wins and I am trying to understand where that logic comes from. [1] <https://git-wip-us.apache.org/repos/asf?p=maven-aether.git;a=tree;f=aether-util/src/main/java/org/eclipse/aether/util/graph/transformer;h=f7f02c5e6a8544da917217d036339617daa0c636;hb=HEAD> Regards, -- Christian --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
