Gradle 3.1: Composite Builds, Here you Go!

Tired of having your changing dependencies slow you down? Gradle 3.1's composite builds provide you with a process of changing and refreshing your dependencies.

koders-gradle
koders-gradle

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.

VIAGradle 3.1: Composite Builds, Here you Go!
SOURCEDZone
SHARE
Sercan Karaoglu had his BS. in Mathematics Engineering Department of Istanbul Technical University. Currently, he develops High Throughput-Low Latency Reactive Microservices and Reactive Stream applications. And passionate about Deep Learning & Machine Learning. He is currently studying his MSc @Department of Computer Engineering and field of Big Data Analytics and Management at Bahcesehir University https://www.kaggle.com/sercankaraoglu https://github.com/SercanKaraoglu http://vertx.io/materials/

LEAVE A REPLY