This message was deleted.

Try taking a look at the sample here: https://docs.gradle.org/7.3/samples/sample_jvm_multi_project_with_code_coverage.html. It’s from v7.3, but it’s still relevant. Basically, on the producing side all Configurations should have some distinct Attribute. And on the consuming side you need to create a ‘hierarchy’ of Configurations: a parent Configuration, and children with more specific Attribute(s) that use

extendFrom()

to extend from the parent.

(sorry for my last message, somehow didn't see the question) As all three artifacts are published in the same consumable configuration, you should be able to simply do it without the need to have separate configurations or

extendsFrom

. So what is the problem you have with that setup?

it sounds like you are trying to do what the jacoco aggregator plugin already does? or is that unrelated to your ask?

you are trying to do what the jacoco aggregator plugin already does

@Shaun Reich I’m duplicating the behavior a bit, but doing it in a custom way to support android and java simultaneously

As all three artifacts are published in the same consumable configuration, you should be able to simply do it without the need to have separate configurations or

extendsFrom

.

You’re right - I’ve actually modified my approach since then to publish the artifacts in 3 separate configurations however, so I guess my question still applies.

val coverageExecFile: NamedDomainObjectProvider<Configuration> = ..
    val _executionData = coverageExecFile
        .get() // TODO find a way to avoid this `get()`
        .incoming
        .artifacts
        .artifactFiles
        .asFileTree
        .filter(File::isCodeCoverageExecutionFile)

I didn’t know how to filter a configuration before, now I do. But I think it’s good to publish in 3 separate configurations?

It's fine to publish in three, then you don't need to filter but simply consume in three just like the jacoco report aggregation plugin does it.

FTR, I technically don’t want to publish as 3, bc I’ll want a outgoing variant that doesn’t include android ui test execution data. so I’ll still need sources/classes to be separate