Hi Stefan,
Thanks for the response!
includeBuild is just a plain old Java method, so you can surround it with for-loops, if-conditions etc. Have a look at the sample I showed in my blog post.
As is includeFlat
, which we already conditionally wrap in our customization. Until includeBuild
has transitivity and defaults to conditional inclusion, I don’t see why we would use it, as we have both already. I did look at the blog post, nice examples for the new feature, but stuff we’ve been doing for a few years now with our customization.
Dropping customizations and adopting the built-in gradle solutions is what we’d prefer to do.
You can do that too, by extracting that logic into a plugin which you apply to all your settings.gradle files.
Really? I’d love to know what magic lets me reliably read the dependencies from the build.gradle
from within the settings.gradle
. If we could do this, then we would not have to list the transitive closure of project dependencies in each project’s settings.gradle
(you basically do this too in the “Splitting Monoliths” example of your blog post). Would love to not have to do that! But this eludes me and runs counter to the Gradle lifecycle as I understand it.
If you’re implying to blindly include the dozens of unrelated projects in a directory, that doesn’t really work. That would be very slow build configure and quite likely may not even work (e.g. thanks to currently unrelated broken project Fubar). Only the related projects should be configured in the build (e.g local transitive dependencies).
As far as a “plugin”, we currently use the apply from:
construct to grab script from a well known internal repository location. Is there support for dynamic plugin resolution in settings.gradle now? Maybe we’re not thinking the same thing.
All of this is really just looking for built-in support to default to dynamically resolving to local projects instead of external dependencies. Whether this is resolved from a directory when using command line, or from a collection of projects in an IDE, it is the same problem. There are reoccurring patterns of general build composition which should just work with practically no effort. Currently this requires maintaining customizations/kludges to make this work in Gradle and the IDEs. When transitivity is added to compositing, it may reduce some of the work, but it is still anything less than automatic.
You’re close when you can do: ‘git clone foo; git clone bar; git clone baz; git clone boz; cd boz; gradle build
’ with standard Gradle, and without a pile of Gradle customizations, repetitious settings.gradle
files, and command line configuration (e.g. no --include-build
).