Customizable Dependency Conflict Resolution


(Hans Dockter) #1

summary: Provide a set of common version conflict strategies beyond the current NEWEST policy (e.g. FAIL). Also allow for custom policies. status: FAIL policy can now be selected in the latest Gradle. code: COMPLETED

Right now Gradle has a single strategy in the case of a version conflict between dependencies. It uses the newest version. Although this often makes a lot of sense it is not always the behavior you want. Some projects have the very valid requirement that the build should fail in the case of a version conflict. Other projects want for compatibility reasons the same policy as Maven where the version least nested in the dependency graph wins. Then there might be also complex custom requirements where people need to implement their own conflict resolution policy.

We want to provide a set of build-in strategies to choose from. We also want to enable hooking in your custom policies.


(Vinod Sajja) #2

Excellent, this is exactly what I was looking for. When we resolve dependencies, it is required to either fail or warn based on the severity of the conflict. For example, using the major.minor.patch.buildnumber format, a conflict in the build number is OK to proceed, however a conflict in the minor version should fail the build.

Couple of other problems I’m facing:

  • Resolved Ivy descriptors use dynamic revision constraints (GRADLE-1663). These dynamic revision constraints shouldn’t be used for analyzing dependency conflicts.

  • There are no dependency reports available on what happened. Ivy reports are generated in the Gradle cache however, maybe the project reporting plugin can be extended to include these.


(sirinath1978m) #3

Also resolution at the IDE is a welcome feature.

One problem I have is the Maven class path container has on version and another call path container within the project has another. These conflict with each other and syntax highlighting and other IDE features break down.


(sirinath1978m) #4

If this feature is to be implemented, fine grain IDE integration and support also needs to be build in so that the IDE project info can be extracted to Gradle and the project configuration and IDE natures can be dynamically changed and influenced. This is a step beyond just generation the project files like what Maven does now.


(Szczepan Faber) #5

Completed in master, will get out with milestone-6. For more info and links to examples, see GRADLE-1899.

It’s a first step in this area. There’s potentially more work involved, for example: enabling completely custom conflict resolution strategies or adding some reporting around conflict resolution.