https://gradle.com/ logo
Join Slack
Powered by
When using attribute-aware variant selection with ...
# community-support
l
When using attribute-aware variant selection with two configurations extending one another, how do you make the extending configurations use the same variant as the parent?
Copy code
dependencies {
  myCfg(project(":common"))
}
configurations {
  myCfg {
    canBeResolved = true
    canBeConsumed = false
    attributes {
      attribute(MyAttributes.PLATFORM, "thisPlatform")
      attribute(MyAttributes.SOURCETYPE, "main")
    }
  }

  // both of these somehow use :common's default export, which is a different jar to the one myCfg consumes
  compileClasspath.extendsFrom(myCfg)
  runtimeClasspath.extendsFrom(myCfg)
}
Configuration-dependent selection works (
project(path=":common", configuration="producingConfiguration"
), but that makes IDEA see common as a wholly separate project. It starts linking me to compiled classes and not updating suggestions in platform based on changes to common, and it's basically unworkable when developing both parts simultaneously.
p
Attributes needs to be declared in resolvable and consumable configurations, not in dependencyScope. If you do have 1 resolvable configurations that wants to resolve an artifact/project with two consumable configurations with the same attributes it will fail.
How does your common consumable configuration look like?
And I would also add a dependencyScope configuration in your consuming project, just to use best practice.
l
I'll be honest, between the toolchain being extremely hardcoded and the workarounds for trying to insert my own transformers in there, I'm not entirely sure how to properly explain the situation. This is definitely the first time I've heard of a 
dependencyScope
configuration though, and I've been reading everything I could find, so clearly there's some information I'm missing on how this is used normally. It's also 3 AM right now and I've been nose-deep in this buildscript since this morning, so that probably has something to do with it. If you'd be willing to take a look, I could really use some more experienced eyes on it. https://github.com/ByThePowerOfScience/DungeonDesigner/tree/architectury For all intents and purposes, the only two buildscripts we care about are common and fabric.
I literally use Gradle professionally and the kind of stuff they make us sift through just to make mods for a children's game makes me want to tear my hair out
Wait a second, I bet the reason IDEA was directing me to compiled sources is because it was using the output of the transformJar task as its sources instead of namedElements If all I care about is that I can compile against the real sources and run with the transformed stuff, I don't even need variants, I just need to have namedElements be compileOnly.
But also, I'd really like to know how to get myself out of this the right way.
p
configurations.dependencyScope/resolvable/consumable are the new role based configurations being incubated since 8.11 or so.
v
Dependency scope basically means non-consumable and non-resolvable. They are the ones you usually declare dependencies on like 
implementation
or 
compileOnly
, hence "dependencyScope". Attributes are never inherited from one configuration to another, even if you extend from one resolvable to another resolvable. If you want attributes to be carried over, you have to declare them on the dependency directly, then those are used.
5 Views
Open in Slack
PreviousNext
Powered by