Over a million developers have joined DZone.

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.

· Java Zone

Discover how AppDynamics steps in to upgrade your performance game and prevent your enterprise from these top 10 Java performance problems, brought to you in partnership with AppDynamics.

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.

The Java Zone is brought to you in partnership with AppDynamics. AppDynamics helps you gain the fundamentals behind application performance, and implement best practices so you can proactively analyze and act on performance problems as they arise, and more specifically with your Java applications. Start a Free Trial.


The best of DZone straight to your inbox.

Please provide a valid email address.

Thanks for subscribing!

Awesome! Check your inbox to verify your email so you can start receiving the latest in tech news and resources.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}