hello! struggling to get my artifact transform to run. I’ve set up a configuration with a particular attribute, I’ve registered the transform as per the docs. I’m resolving some artifact from something that has gradle-module-metadata. The attribute on the variant from this producer, has the same type as the

from

in the transform. What I don’t understand is: •

Incompatible because this component declares attribute 'org.gradle.usage' with value '<thing to convert>' and the consumer needed attribute 'org.gradle.usage' with value '<desired>'

• This is gradle 8.4. I’m getting a

NoMatchingConfigurationSelectionException

and I’ve traced through the code for the failure path. It sounds like the configuration at this point should not have an attribute on it so it can pass the

isMatching

check, but I’m not sure when I should put the attribute on it? By the time it reaches

AttributeMatchingConfigurationSelector.selectVariantsUsingAttributeMatching

is it too late to do artifact transforms? • In a separate instance of me using artifact transforms successfully, it’s a very similar setup (albeit not with GMM) but using the

artifactType

attribute converting from

tgz

to

directories

. Why is it okay for the

Configuration

to have that attribute and the transform be active, but in the above, it refuses to match the attribute? • Should I be forcing the issue with an

ArtifactView

?

Actually it's a bit of a mess, for example

artifactType

is an attribute on artifact, not on the variant so that's a significant difference in your two cases. Can you maybe knit an MCVE that shows your non-working try?

sorry was quite late in the day for me when you replied. I’ve made a repro here: https://github.com/felixdesouza/gradle-artifact-transform-reproducer build scan: https://scans.gradle.com/s/vlbvubqqo7zwm different cases: https://github.com/felixdesouza/gradle-artifact-transform-reproducer/blob/kotlin-dsl/build.gradle.kts failing github actions: https://github.com/felixdesouza/gradle-artifact-transform-reproducer/actions/runs/9161382659/job/25186099784 so I played around a bit more, and it seems that if I don’t specify any attributes on the

Configuration

, and instead make an

artifactView

with the attribute I want, then I’ll get the transform to run. I’ve added that as a case above.

@Jendrik Johannes please correct me if I got it wrong, as the attribute topic is always a mess to understand, and I'm also always not sure I fully get it right.

confusing is that lots of things have attributes, and it’s not immediately clear how they contribute to resolution

Yes, as I said, it is pretty messy. Configurations have attributes, artifacts have attributes. The artifact transforms are artifact transforms, not variant transforms. For selecting a variant, the attributes on the configuration level have to match and you cannot "transform" these. After a variant is successfully selected, an artifact transform and further transform the artifact. For

artifactType

it works on the configuration because it is a artifact-level attribute, so it does not contribute in selecting the variant. So despite the

artifactType

not matching, the variant can be selected, and then the artifact transform can transform the artifact to the intended state. With the artifact view, the configuration resolved the variant successfully as you did not request the usage attribute and not requesting an attribute is compatible to the attribute having any value. Then for the artifact view the transform can kick in to transform the attribute to the intended state.

Should I have multiple separate configurations and then combine them via

extendsFrom

?

If I got you right, this will not help unless you declare the wanted attribute on the dependency instead of the configuration, but then you could right away do it on the "one" configuration too, because

extendsFrom

just means that it is like you declared the dependencies on the extending configutaino like you declared them on the extended configuration. But the attributes you declare on the extended configuration are not relevant when resolving the extending configuration. For that only the attributes declared on the extending configuration (i.e. on the configuration you are actually resolving) are relevant.

Interesting, I think in the general sense that distinction makes a lot more sense. Thank you! I think the other point of confusion for me is that the configuration in the docs makes it such that the consuming

Configuration

has an attribute request of

minified=true

How does this not fail when trying to resolve via variant attribute matching? As this doesn’t fall into the above cases you outlined? i.e. if I request an attribute and the producer doesn’t have it at all (vs it does but it’s different), what is supposed to happen here? Would it fail harder if the upstream repository used gradle module metadata or something else? Effectively, when is putting an artifact on a

Configuration

going to contribute to artifact attribute matching vs variant attribute matching? Having

artifactType

automatically work is probably what has caused me the most confusion i.e. it would make more sense that to do any sort of transform you have to use an

ArtifactView

. it’s a bit more cumbersome but definitely better drives the point home. But alas, we are here now 😅 . IMO the docs should focus on the

ArtifactView

approach in addition to the existing, because the above

unless you declare the wanted attribute on the dependency instead of the configuration

is this for variant attribute matching or artifact attribute matching? if I’ve understood correctly. (Assuming it’s also variant attribute matching). I should be able to add an attribute when adding a dependency. That should then be checked against the producing attributes and I could get the “mutual exclusion” I care about that way? FWIW, I control both consumer and producer.

How does this not fail when trying to resolve via variant attribute matching?

minified

is not an attribute on the configuration You add it with

artifactTypes...

with value

false

to all

jar

attributes and thus it is like

artifactType

an attribute for the artifact, not the variant, so the artifact transform can do its work after the intended variant was resolved.

is this for variant attribute matching or artifact attribute matching?

I'm not fully sure, but I think for variant matching, because first the variant has to match before the artifact can be transformed. And setting it on the dependency should be like setting it on the configuration just that it is only for that dependency and also carried over to extending configurations as it is delcared on the dependency.

So just to be clear: (copied from the docs)

configurations.all {
    afterEvaluate {
        if (isCanBeResolved) {
            attributes.attribute(minified, true) 
        }
    }
}

now has a different meaning because we’ve added

minified

as an attribute to an

artifactType

?

Did I mention it is a great mess? 😄

haha! thanks! I think I will play around with this

No idea about

onlyForAttribute

, never used it. But from the description I'd say it should work for attributes declared on the configuration and on the dependency alike. If it does not, you might have discovered a bug that you should knit into a reproducer and report to Gradle.

As I don’t expose a raw

DependencyHandler

block to the plugin consumers, I control what gets added to the configuration.

You might be interested in this that is added in 8.8. Of course it is incubating and also only works with 8.8+, but it might be interesting or something for the future: https://docs.gradle.org/8.8-rc-1/userguide/implementing_gradle_plugins_binary.html#custom_dependencies_blocks

The other option is just calling

RepositoryContentDescriptor#includeModule

and

RepositoyrContentDescriptor#excludeModule

on the respective repositories.

Maybe better use

exclusiveContent

instead? https://docs.gradle.org/current/userguide/declaring_repositories.html#declaring_content_exclusively_found_in_one_repository

I could do this with an

afterEvaluate

but seems a bit meh.

Not just "meh", the main effect of

afterEvaluate

, especially in plugins, is to add ordering problems, timing problems, and race conditions.

Do you have any ideas what would be decent to do here?

Not really, as I didn't fully get what you try, sorry. Maybe some MCVE could bring clarity.

Not just “meh”, the main effect of

afterEvaluate

, especially in plugins, is to add ordering problems, timing problems, and race conditions.

haha yeah, I try to remove it where possible in our plugins, I can’t count how often it has caused problems.

You might be interested in this that is added in 8.8.

Of course it is incubating and also only works with 8.8+, but it might be interesting or something for the future: https://docs.gradle.org/8.8-rc-1/userguide/implementing_gradle_plugins_binary.html#custom_dependencies_blocks

I saw this in the release notes, it’s very neat. We are struggling with our gradle 8 migration across the board, so it’ll be a while before we can roll our plugins to use the block. But it is very neat from the look of things. Yeah, I will put up a reproducer, thanks!