Our journey with Gradle started one and half years ago with this presentation. Everybody in the company just loved its expressive and easy-to-understand structure and realized that a plugin model was the wrong level of abstraction. Instead, language-based approaches were the right one in terms of their flexibility for the long term.
So it didn’t take long for almost 50 members of the development team to change the whole build infrastructure with Gradle. Gradle doesn’t just throw away the foundation that other build tools brought. Instead, it builds up easily and more powerfully on top of others while remaining 100% compatible with them. Therefore, this made Gradle not an alternative but an upgrade for us.
While we were migrating projects, simple pom.xml projects required only a few steps, such as; “gradle init,” but others needed more effort. Everything was good with Gradle except for one thing — “composite builds.”
And finally, our most-requested feature came out with Gradle 3.1, and now we love Gradle more than ever.
Composite Builds: Why Are They Important?
If you are developing highly modular applications, at some point, you may need to stop and change one of your dependencies. In the meantime, this change must be visible to others. So, it needed to be built and published to the shared repo, which could be local or remote. After that, your actual project should refresh its dependencies. Because the project depends on another project, every time the referenced project is changed, the whole process needs to be repeated. Therefore, as development kept on going, this repeated process caused some frustrations.
So What About an Alternative?
To make this process go in one pass, we can choose to create multi-project builds. But when we do this, this may lead to coincidental cohesion in our builds. Because most of the time our dependencies are generic, and not project-specific, this makes this particular solution not fit for us, even if it satisfied the one-pass-build case.
Gradle 3.1 Composite Builds
This is a very important feature, and there is more room to develop in this area. For now, this provides us with the capability of keeping dependencies separate and builds the actual project with an option for referring to the dependency.
- This helps us the split up the project into smaller, independent builds. Thus, we can now have painless modules at scale.
- We can now quick-fix the dependency and see the result right away.
And all this requires one line:
gradle test --include-build /path/to/some-dependency
I recommend you to use this and provide them with some feedback for improvement in this area. This will help Gradle and its community to make things better.