https://gradle.com/ logo
Join Slack
Powered by
This message was deleted.
# dependency-management
s
This message was deleted.
j
tinkering with
Copy code
dependencies.attributesSchema {
    attributes.clear()
}
but can’t figure out how to silence this feature
v
What makes you think the info is incorrect? You should not try to somehow suppress it, but if it is indeed wrong, fix the producer project as it is your own. If it were a foreign one that indeed is published wrongly, there would be proper ways to fix the attributes, but this shouldn't be done in that case most probably.
As far as I can see from a quick look, you use a Java 17 toolchain for the tck module, so the attribute is set to 17
m
agreed, this message shouldn't be ignored
j
i have a specific reason in this case, and it’s a “i know what i’m doing, so please gradle get out of the way” — java compiler doesn’t support 
--release 8
when using text blocks even though the bytecode of a text block is indistinguishable from a concatenated string. it’s internal only to this project
how do i fix the producer while using java 17 toolchain?
really i just want to opt out of this variant matching for this case, and i feel like it should be possible to tell gradle to leave it alone
are the attributes somehow configured on the configuration such that i can tell rewrite-java-11's 
testImplementation
to accept “java 17” dependencies?
v
But how do you make it that the class version works? The class file knows it is compiled for Java 17+ and Java 11 will refuse to read that class file.
m
change the producers outgoing variants attributes
j
how?
But how do you make it that the class version works?
bytecodes were postprocessed to ensure they were java 8 compatible after compilation, and the version byte was manipulated as part of this. so gradle thinks it compiled 17, but the class file itself will be 8 compatible
v
Ah, I see. I guess setting target compatibility instead of using 
--release
will also not work?
Then yes, you should probably just change the attribute on the outgoing configuration as @melix said, so that it matches the acutal produced artifact.
j
i thought that was deprecated? it’s unclear to me what target compatibility does anymore
how do we change the outgoing attribute? i agree that does sound best
m
something like:
Copy code
configurations.all {
    if (it.canBeConsumed) {
        it.outgoing.attributes.attribute(TargetJvmVersion.TARGET_JVM_VERSION_ATTRIBUTE, 8)
    }
}
(untested, from memory)
j
ah, interesting
v
Should be without the 
outgoing
I think though
You can also check the result using the 
outgoingVariants
task
j
You can also check the result using the 
outgoingVariants
task
good to know
thanks much to both of you. this did it:
Copy code
configurations.all {
    if (isCanBeConsumed) {
        attributes.attribute(TargetJvmVersion.TARGET_JVM_VERSION_ATTRIBUTE, 8)
    }
}
👌 1
m
this is the right way to fix it btw, rather than trying to silence. You are basically telling Gradle that your outgoing variant is compatible with Java 8.
💯 1
Open in Slack
PreviousNext
Powered by