The greatest feature of composite builds is definitely their IDE integration. Being able to make a change and immediately see its effects on other builds is very cool.
There are, however, cases where that behavior is not desired, for example when you are developing a cutting-edge version of a library and don’t want to immediately switch all consumers to it. The composite build documentation has a section on just that, however it requires modifying the build file of the consuming project,.
I have a few projects which can be developed independently. Some of them consume artifacts produced by others. My goal is to develop a separate meta-project which would unite them all into a big composite build, for ease of development. Each build should be able to act as a substitute, but on 2 conditions:
- The requested version matches exactly what’s currently in the substituting build
- The logic that implements this should only exist in the meta-project, since by default those separate projects don’t (and shouldn’t) know about each other
This implies that this has to be somehow configured in settings.gradle.ktsof the meta-project in the includeBuild directive, however the API seems to lack the ability to examine the projects of included builds and their versions. Which, upon first glance, should be fine, because included builds are separate entities and interaction with them should be limited. However, Gradle itself does have the capability to inspect included builds - that’s what it does it order to perform build substitutions.
Also, the same documentation section says:
Gradle does not consider published versions during resolution by default
which implies that there is a way to consider it?
I did an SO post on this issue a couple of months ago, but it didn’t seem to go anywhere. So I shall ask here: is there currently a way to achieve what I mentioned or should this be a new feature request?