Understanding Gradle #13 - Aggregating Custom Artifacts

[@AlexanderBartash]

Great explanation.
You can create a configuration which extends from implementation or compileClasspath or runtimeClasspath and set on it
attributes {
this.attribute(DocsType.DOCS_TYPE_ATTRIBUTE, objects.named(DocsType.SOURCES))
}
This will instruct Gradle to pull soruces, instead of regular jars, but it works only if src variant is present in the published Gradle metadata file.

[@rajnhard]

Your videos == good stuff

[@VladimirSitnikov]

Nice representation of variants and attributes. However, it looks like there's an error with usage=java-sources at 10:31. The diagram looks like "java-sources of business-logic module depends on java-sources of data-model", however that does not really make sense. I think app's java-sources should point to both business-logic and data-model. WDYT?

[@jjohannes]

Thanks and good point. The diagram is correctly showing what is modelled in the example. Whether that is a good way of tackling this particular use case, can be discussed though. That's also what I meant when I said using 'lenient(true)' might not be the best solution.
In the example I say for all libraries:
configurations.create("sourcesElements") {
extendsFrom(configurations.implementation.get())
...
}
By that, I get all the transitive dependencies defined in 'implementation'. That's why there is a transitive dependency from "business-logic" to "data-model". But that's also why there is a transitive dependency from "business-logic" to "commons-lange3" (which annoys us here).
The reasoning to still do it like this is that I want to say: "Gradle, just give me all source code that belongs to my application. I don't want to declare anything in addition. Use the classpath/dependencies we already have to finde everything."
An alternative approach would be to explicitly define all dependencies to the projects from which we want to aggregate. For that, we would remove the "extendsFrom(...)" above and then we will not get any dependencies transitively.
In "app" (and/or the application convention plugin), we can then do something like this:
val source = configurations.create("source")
val sourcesPath = configurations.create("sourcesPath") {
// Don't do this anymore: extendsFrom(configurations.implementation.get())
extendsFrom(source)
...
}
dependencies {
source(project("data-model"))
source(project("business-logic"))
// List all projects from which we want to aggregate in scope "source" here...
}
But then you explicitly define dependencies to all the projects (again) here. If that is what you want, then that's the better solution.

[@VladimirSitnikov]

Right you are. The diagram is indeed consistent with the code and the explanation. I missed sourcesPath.extendsFrom(implementation)