Skip to content

Rework default conflict resolution approachΒ #185

@jjohannes

Description

@jjohannes

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:

  1. Conflicts where "select highest version" is a good defaul (library was relocated). For this we keep the behavior as it is
  2. 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.

Metadata

Metadata

Assignees

No one assigned

    Labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions