Extend rule for `org.bouncycastle`

[boris-petrov]

There are org.bouncycastle:bcprov-jdk15on and org.bouncycastle:bcprov-jdk18on which are conflicting.

Same for bcmail, bcutil, bcpkix and maybe others.

[jjohannes]

This would be a candidate to solve like we did for Guava in the past. If the Java version used defines which variant to pick, we could merge all variants together into a single component (from the Gradle viewpoint) and then use the org.gradle.jvm.version attribute (and not only capabilities) for Gradle to decide based on the Java version.

See this example: https://docs.gradle.org/current/userguide/component_metadata_rules.html#making_variants_encoded_in_versions_explicit

[jjohannes]

Okay that's crazy:

Let's just do the capabilities similar to the other libraries at first.

[boris-petrov]

@jjohannes there is also bcjmail-jdk18on (note the extra j) - that's a Jakarta version of the bcmail artifact... so I guess either in this rule or in the Jakarta vs javax rules this could be added... not sure how exactly. This is complete madness. :smile:

[boris-petrov]

@jjohannes sorry to ping you again but you might have missed this. :)

[jjohannes]

Thanks for the ping.

[britter]

We've reviewed this today and realized that bcjmail artifacts are already covered, see https://github.com/gradlex-org/jvm-dependency-conflict-resolution/blob/a795278db454e9b246064d68f7c9efef11a46358/src/main/java/org/gradlex/jvm/dependency/conflict/detection/rules/CapabilityDefinition.java#L82-L84