>the version conflict is caused by a JAR being split in many >JARs, but this cause does not need to be the focus of the discussion.
I'm fine if the solution for consumption of multi-module libraries goes into a different proposal. However, there's no viable proposal that could handle this scenario. There are much bigger proposals like "let's build maven extension that would replace dependencies based on certain rules". Sure it would be helpful, however, it would be an overkill for a common cases like consuming multi-module libraries. Gradle's experience justifies that: they have both platforms and component metadata rules to cover different use-cases. >Build on top of Guillaume's "Configurable Dependency Version Resolution Strategy" [1]. It addresses a different problem, and it does not help for "jar split" scenarios. Of course, implementing both proposals would yield much better results, however, Guillaume's proposal alone is not sufficient. > Vladimir's proposal could be another resolution strategy Adding a strategy for every new request won't scale. Frankly, I would not consider adding a strategy unless there's a desire to make it default one day. >At least on my side, especially when BOM imports are >involved. I tend to have an empirical approach I'm with you here. I want the tool to produce meaningful and workable resolution by default even if the user does not understand every bit of Maven specification. The users should get workable apps by default, while the pros would still have options to fine-tune if they need it. Both claim 1 and claim 2 express exactly this motivation: there's a demand in real-life projects, and Maven could improve in the particular case of consuming multi-module libraries. Vladimir
