This message was deleted.
# community-support
s
This message was deleted.
j
You should try to use attributes to match the configurations. On the consumer side (where you collect things) you can do something like this:
Copy code
configurations {
    myConfigurationConsume {
        canBeConsumed = false
        canBeResolved = true
    }
    attributes {
        attribute(Usage.USAGE_ATTRIBUTE, objects.named("my-usage"))
    }
}

rootProject.subprojects.forEach(pr -> 
    myConfigurationConsume project(pr.path)
)
And on the producer side you declare the attribute as well:
Copy code
configurations {
    myConfiguration {
        canBeConsumed = true
        canBeResolved = false
    }
    attributes {
        attribute(Usage.USAGE_ATTRIBUTE, objects.named("my-usage"))
    }
    ...
}
Then when you resolve, you filter out the projects that fail to resolve because they do not have "myConfiguration" by using a lenient artifact view:
Copy code
myConfigurationConsume.incoming.artifactView { lenient(true) }.files
A even 'nicer' solution would be to get rid of the
subprojects.forEach
loop completely. If you have something like an "app" project, which already has dependencies to all your projects (e.g. on the runtimeClasspath) you could put the
myConfigurationConsume
there and then let it extend
implementation
. Then it automatically has all your subprojects. That's how I do it with collecting the source code of all projects in this example: https://github.com/jjohannes/understanding-gradle/blob/main/13_Aggregating_Custom_[…]gic/java-plugins/src/main/kotlin/my-java-application.gradle.kts
It's also how Gradle's aggregate-test-report and aggregate-jacoco plugins do it internally.
m
That's awesome, thank you! I'm not sure that this solves my problem completely, though, because this build is complex in a not-so-good way 😕 I might not have a classpath with all the relevant source projects in the project where I need the refer to those files. This is a big and complex build, so I cannot easily be sure about that and even if it works now, that might not be true forever. So ideally, I'd like a way to collect all projects applying a certain plugin.
j
I think the "applying a certain plugin" is difficult without running into cross-project configuration (and timing) issues.
Creating dependencies to all projects. And then using the "lenient" to filter, should be okaish though.
So you would not check if the project applied a plugin, but the plugin you applied in the project would add the configuration with the attribute (or add the attribute to the configuration, if it exists already).
So instead of using the plugin ID to filter, you move that to the attribute on the configuration.
m
Looking at the code you posted above, it seems to me now like it would already do what you described. Is that correct?
j
Yes it should (haven't tested though).
m
Awesome, thx!