Dynamically compose list of dependencies in composite build

Help/Discuss
1

Hello!

I am the developer of projectB which is an add-on to projectA and has dependencies to its subprojects. I have created a composite build ideimport so that I can easily import projectB into an IDE with all its dependencies. The directory structure looks like this:

ideimport\
|___ projectA\
|____|___a\
|____|___b\
|____|___c\
|____|___d\
|____|___e\
|___ projectB\

This is how I have added the dependencies to build.gradle for projectB:

// Check if projecB is part of a composite build
boolean inComposite = gradle.parent != null
// If so apply dependencies that reference to projectA
if (inComposite) {
	dependencies {
		implementation 'projectA:a' ,
			'projectA:b',
			'projectA:d',
			'projectA:e'
	}
}

By importing ideimport as a gradle project into an IDE I will import projectB with the correct dependencies. At the same time I am still able to run gradle tasks for projectB as a standalone project.

projectA’s included projects will change over time, e.g. a project f might be added and also needs to be added to projectB’s dependencies. However I expect that I might not always notice such a new project because in reality there are already more than 10. My question is: can I somehow dynamically compose the list of dependencies to projectA? As far as I now there is not a sort of wildcard I could use for the subprojects. Is it maybe possible to get the list of projectA’s included projects through gradle.parent and then loop through that list to get the right dependencies? Or is there another way this could be achieved?

Cheers,

Henk

1 Like
2

Did you manage to solve this? I have exactly same setup and problem and even now there isn’t anything built-in from Gradle

3

No you cannot really list the subprojects of another build in a composite build and depend on all those.
And even if you could, you most probably should not.

If you really need something like that, you could maybe have one project in A that depends on all other projects in A using allprojects or subprojects (the lists, not allprojects { ... } or subprojects { ... }) and then depend on that “collector” project of A in B.

But in probably most if not all situations you should not do that, but declare in B only what you actually use in A explicitly.