Expressing optional Java 11 dependencies in published metadata

Hi,
I have a library that uses JAXB, which has been removed from Java 11. My library must be compatible with both Java 8 and Java 11.
Building & testing the library is easy enough, as I add the following dependency if a Java 11 runtime is detected during the build:

implementation “com.sun.xml.bind:jaxb-impl:2.3.3”

However, my goal is to publish metadata with two variants, one with attribute org.gradle.jvm.version set to 8 without the JAXB dependency, and one with attribute org.gradle.jvm.version set to 11 and the JAXB dependency.
I’d also like for this to be transparent to the consumer, i.e. that its dependency declaration remains

implementation “foo:bar:1.0.0”

Is this possible with the current version of Gradle? By declaring a variant of the default capability?

1 Like
implementation “com.sun.xml.bind:jaxb-impl:2.3.3”

What’s your approach of implementing JDK 11-specifics? I have a custom gradle file containing statements like the following:

if (JavaVersion.current().isJava8())
{
	return
}

dependencies
{
	compileOnly 'javax.annotation:javax.annotation-api:1.3.2'
}

An din build.gradle:

apply from:		'buildSrc/src/main/java/BuildByJdk11Workarounds.gradle'

Is this possible with the current version of Gradle? By declaring a variant of the default capability?

Did you already had a look at the official docs? Those sound to me like your goal could be reached by using Gradle Module Metadata:

https://docs.gradle.org/current/userguide/variant_model.html#sec:mapping-maven-ivy-to-variants
https://docs.gradle.org/current/userguide/component_metadata_rules.html

Crosspost:

For JDK 11 specifics, I do it directly in the build.gradle:

if (JavaVersion.current().isJava11Compatible()) {
  // JAXB removed from JDK 11
  dependencies {
	"com.sun.xml.bind:jaxb-impl:2.3.3"
  }
}

I have already read the official docs, and used the links you referenced to solve my ivy-maven mixed repositories problems.
I should have been more explicit in the title, but what I want to achieve cannot be expressed without Gradle metadata (i.e. it can’t be expressed in Maven nor Ivy), hence the variants & capabilities reference in the question.
However, after reading and experimenting, I must have missed something as I can’t find a simple way to express the constraints I have mentioned.
(And thanks for the cross-post reference, after one week without an answer, I tried my luck on SO)