search

jjohannes / gradle-project-setup-howto

How to structure a growing Gradle project with smart dependency management?
Apache License 2.0
155 stars 18 forks source link

Bouncy Castle version alignment issue #61

Open mqware opened 3 weeks ago

mqware commented 3 weeks ago

I recreated this issue here: https://github.com/mqware/gradle-project-setup-howto/tree/bouncycastle

I added two new dependencies to the project, com.verhas:license3j and org.apache.activemq:artemis-core-client. The first one has a dependency on org.bouncycastle:bcpg-jdk15on:1.60, while the second has several bouncycastle dependencies from the jdk18on series, e.g.: org.bouncycastle:bcprov-jdk18on:1.78.

The question/problem I have is how to upgrade org.bouncycastle:bcpg-jdk15on:1.60 to org.bouncycastle:bcpg-jdk18on:1.78? I tried many different things without success. A simple version constraint or the alignment feature of the dependency-rules plugin didn't work, because the artifactId of the two libraries are different. The only thing that worked is to patch the module directly and remove the old jdk15on dependency and replace it with a new jdk18on dependency. And then I could use an alignment rule to align the versions. But I am wondering if there is a better way to achieve this.

Thanks, Peter

jjohannes commented 1 week ago

Hi @mqware. There is no good solution to these cases I am aware of at the moment. It's a weakness when combining Capabilities and Constraints like this. As the constraint does not get activated in such cases as you correctly observed.

I would use the same solution as you: replace the dependency in a rule.

For completeness: Another feature Gradle offers are replacement rules. I am hesitant though to add this into the mix to not have too many concepts combined. My understanding is that everything around "capabilities" is meant to be a "better" alternative to replacement rules. But in this one use case, the "old" replacement rules would work better.

There are considerations to use the replacement rule concept in the jvm-dependency-conflict-resolution plugin - https://github.com/gradlex-org/jvm-dependency-conflict-resolution/issues/35. That could be reconsidered and maybe it could even be hidden behind the DSL the plugin offers to make cases like the one you describe, just work (if you use the plugin).