-
Notifications
You must be signed in to change notification settings - Fork 15
Open
Labels
a:enhancementNew feature or requestNew feature or requestin:capability-conflictThings related to capability conflictsThings related to capability conflicts
Description
Right now, we always select the highest version. Which is not always a good default (see for example #114). In the team we came up with the following idea to improve the situations:
Split capability conflicts into two categories and add warnings:
- Conflicts where "select highest version" is a good defaul (library was relocated). For this we keep the behavior as it is
- Other conflicts (alternative implementations etc) for this, we do "select highest version" as a "best guess" so that users are not confronted with failing builds right away when introducing this plugin. But we will issue an warning via Gradle's new Problem Reporting API. Then, users who strife for a clean setup, have to address all warnings and make explictit decissions using the
conflictResolution { select(..., ...) }DSL we already have. The warning message should contain clear instructions on how to use the DSL. It could print a list of all possible solution so that it is clear to the users what they can do and why they need to do it.
boris-petrov and Vampire
Metadata
Metadata
Assignees
Labels
a:enhancementNew feature or requestNew feature or requestin:capability-conflictThings related to capability conflictsThings related to capability conflicts