https://gradle.com/ logo
Join Slack
Powered by
I have a Gradle plugin with a custom attribute. Wh...
# community-support
p
I have a Gradle plugin with a custom attribute. Why does Gradle select a (unwanted) variant if the requested attribute is not found, mostly jvmRuntimeElements? I added the attribute to the attributeSchema. Do I still need to add a AttributeCompatibilityRule to ignore a dependency without the requested variants? In theory, I would expect the Gradle build fails.
m
Variant with missing attributes are treated as compatible by default
Copy code
A candidate is considered compatible if its value matches the consumer's value exactly, passes the attribute's compatibility rule or is not provided.
That’s quite annoying. Last time this happened to me, I was able to workaround by passing an explicit configuration to my dependencies but that doesn’t cross the publishing boundary 😕
I don’t even think an 
AttributeCompatibilityRule
would work as it’s called later on in the algorithm
p
Hm, thanks. Will overwriting/adding the gradle usage attribute work? Even failing is a better dev ex when writing a custom plugin because seeing some wrong files in your tasks is very annoying.
m
I’d be anxious at touching 
Usage
as other plugins might rely on some edge case behaviours there
I think your best bet is to define your own attribute 
com.mydomain.MyAttribute
and set it to 
"poison"
on all the artifacts that are not yours... Not great but at least doesn’t touch other attributes (but touches other artifacts 🤷)
p
Well, thanks. And I guess, I have to split my dependencyScope configurations. Currently, I reuse them because I am lazy, but this results into this error.
👍 1
Another question: when do I need to add the attribute to the attributeSchema? Only when using it with a resolvable configuration? Or with the outgoing consumable too?
m
I’m not sure TBH. So far I’m not adding the attributes to the attributeSchema and it hasn’t been an issue so far....
I think it’s only used for custom compatibility/disambiguation rules?
v
When I last asked about this, I think I was told to always add it to the attribute schema. I'm not sure when it is hard required or in which cases it changes behavior, but better always add it.
🤷 1
👍 1
https://docs.gradle.org/current/userguide/variant_attributes.html#creating_attributes_in_a_build_script_or_plugin since then got updated to say > Attributes should always be declared in the attribute schema found on the 
dependencies
handler > [...] > Registering an attribute with the schema is required in order to use Compatibility and Disambiguation rules that can resolve ambiguity between multiple selectable variants during Attribute Matching.
p
But if I understand it correctly, this is only required when resolving 🤔 because there are no rules for consumable/published configurations
v
With the explanation added (the second sentence I quoted) I'd say so, yes. When that was added the first sentence also was changed from "must be" to "should always be". 🤷‍♂️
m
Could you use a separate publication instead of separate variant? => no attribute issue
p
I don’t yet publish them, it’s only cross projects. But I will do this in the future . Basically, it’s a microservice framework and until now, a mono repo is required. All these services (located in a subproject) will be configured (url, parameters etc.) in a infrastructure subproject, including getting the classpath of the services. This configuration uses Kotlin, that will create a final OpenAPI definition. This one is already published.
m
If you’re in a monorepo, you can bypass variant resolution completely by specifying the exact configuration you depend on
Copy code
dependencies {
  add("myconfig", project(":project1", "myConfiguration"))
}
p
Yes, I am aware but I don’t like passing the configuration explicitly 😅
👍 1
m
Fair enough. Not that i’m a huge fan either but between that or debugging the variant resolution alorithms I chose that 🙃
p
I did win, with your help 😎
🎉 1
👌 1
3 Views
Open in Slack
PreviousNext
Powered by