This message was deleted.

consumer/build.gradle.kts

dependencies {
    attributesSchema {
        attribute(Features.FEATURES_ATTRIBUTE)
    }
}

val producerConfiguration by configurations.creating {
    isCanBeConsumed = false
    isCanBeResolved = true
    isVisible = false
    attributes {
        attribute(Features.FEATURES_ATTRIBUTE, "one,two")
    }
}

dependencies {
    producerConfiguration(project(":producer", configuration = "default"))
}

tasks.register<Copy>("copyLibs") {
    from(producerConfiguration)
    into(layout.buildDirectory.dir("features")
}

https://docs.gradle.org/current/userguide/variant_attributes.html#sec:abm_algorithm

Each candidate’s attribute value is compared to the consumer’s requested attribute value. A candidate is considered compatible if its value matches the consumer’s value exactly, passes the attribute’s compatibility rule or is not provided.

So yes, works as designed I'd say.

Sorry, I saw you also replied in the other thread. I wrote it here to have a broader issue, but you got it fast I would say..that's terrible then, default will always match any attribute requirement.

I'm sure it has some sense. The attribute matching in Gradle is not trivial. Needs some time to wrap the head around.

maybe then it's my usage of the feature

Or maybe feature variants / capabilities?

or maybe configurations.configuraEach and add my attribute

Yeah, that would be like the example in the docs, just that there it is added to the artifacts

capabilities are to make sure you only use one dependency with that capability, I don't think it's meant for my usecase

No, capabilities are not only for that. They are also the driver behind the feature variants functionality

another option is..

configurations["default"].attributes {
    attributeProvider(Features.FEATURES_ATTRIBUTE, "...")
}

It feels to me like maybe the attribute compatibility rules are not configured correctly? It sounds like anyone fetching who requests your attribute should be incompatible with anything not declaring your attribute?

I removed the compatibilityRule (it's not called when the producer didn't set the attribute)

See my quoted part of the docs above @Chris

hmm… yes - maybe @CristianGM you could make this more concrete? What does

Features

represent and what values can it take?

our libraries can have a list of features they implement (not like capabilities, not exclusive) We want to create "bundles" including just the libraries that have only "included features".

Ahh yes… I’m getting deja-vu. The right way to model this is with capabilities/feature variants as @Vampire suggests (I believe)… but I’ve hit issues with this stuff in the past. @Louis Jacomet care to help out here 😉?

note here I'm using

incoming.artifactView { lenient(true) }

to be able to run the task while excluding artifacts

Two things: • That rule on marking missing attribute as compatible with a request asking for it is actually a mandatory feature for any kind of backwards compatible evolution of variants. And since in the context of published metadata, backwards should be forever, there is just no way around it. I wished we had some public doc explaining that more in detail. Please trust me for now 😉 • I am not sure the current system can represent what you are trying to do because of the above. If your setup enhances existing variants, in a compatible way - that is they are selectable by a consumers just looking for a runtime classpath for example - then you will have to filter out the results outside of resolution itself.

I have made it, and it works fine, is just that I didn't expect that behaviour and thought it was a but. I would say 🙏 🙏 🙏 improve the docs to make it clear (and to understand the reasons).

Then I would say open a doc improvement request ticket (or PR). :-)