> > I couldn't find a way to identify redundant constraints either for > cleaning up in the long run the constraints. Any ideas how this could be > tackled? >
Exactly. It's a problem I keep struggling with elsewhere as well. The only workflow I managed to figure out was to keep the constraints centralized, remove them upon a batch of upgrades, then selectively re-add those that are still needed. Doing this manually would involve a lot of tinkering with gradle's internals, I think... You could try to clone/recreate selected configurations, then resolve them without constraints and compare the results. I don't know how complex it'd get. > What would be the drawbacks / risks for allowing multiple versions of the > same library in case of transitive dependencies and their resolution? > The drawback is that you'd end up having multiple JARs on the classpath - their ordering will affect class resolution, so probably not acceptable. Is that even possible if we lock dependency versions? Gradle will align versions of the same dependency (or complain) within a single configuration but for two "independent" configurations, the same catalog version may resolve differently depending on transitives. It's mentioned here: https://docs.gradle.org/current/userguide/resolution_strategy_tuning.html#resolution_consistency and it's the reason gradle's java plugin provides odd hacks like this one: https://docs.gradle.org/current/userguide/resolution_strategy_tuning.html#sec:java_consistency https://docs.gradle.org/current/javadoc/org/gradle/api/plugins/JavaResolutionConsistency.html It won't help if you have custom configurations that you want to keep aligned - that's the reason I wrote that custom plugin... Dawid
