# Introducing Composite Builds

DevFeed: [Introducing Composite Builds](<https://devfeed.tech/articles/introducing-composite-builds-24649.md>)

Original publisher: [Read original article](<https://blog.gradle.org/introducing-composite-builds>)

Author: Stefan Oehme

Published: 2016-10-12T04:00:00Z

Content type: release

Language: en

Sources: [The Gradle Blog](<https://devfeed.tech/sources/the-gradle-blog.md>)

Topics: [Gradle](<https://devfeed.tech/topics/gradle.md>), [Development](<https://devfeed.tech/topics/development.md>), [Software Engineering](<https://devfeed.tech/topics/software-engineering.md>), [Refactoring](<https://devfeed.tech/topics/refactoring.md>)

Tags: [code](<https://devfeed.tech/tags/code.md>), [debugging](<https://devfeed.tech/tags/debugging.md>), [dependencies](<https://devfeed.tech/tags/dependencies.md>), [dependency](<https://devfeed.tech/tags/dependency.md>), [development](<https://devfeed.tech/tags/development.md>), [gradle](<https://devfeed.tech/tags/gradle.md>), [release](<https://devfeed.tech/tags/release.md>), [software-engineering](<https://devfeed.tech/tags/software-engineering.md>)

## AI overview

Gradle 3.1 introduces composite builds, which join multiple independent Gradle builds and build them together. The article explains how this can replace binary dependencies with project dependencies for faster cross-project development and testing, including work involving plugins, IDEs, refactoring, and debugging.

## Source excerpt

It's not every day that we get to announce a feature that revolutionizes several software engineering workflows, but today is that day. Composite builds, a new feature in Gradle 3.1, enables an entirely new dimension in project organization. Composite builds are a way to join multiple independent Gradle builds and build them together. The brevity of that statement does not fully convey all of the new possibilities, so let me show you how this will make your life as a developer a lot easier. Joining projects Many organizations split their code base into several independent projects, each having a dedicated repository and release cycle. Integration between the projects is managed using binary dependencies, e.g. JAR files published to a binary repository like Artifactory. This approach has many advantages, but can be inefficient when trying to rapidly develop and test changes that affect two or more of these projects at once. Imagine for a moment that you are fixing a bug in a Java library that your application depends on. Your workflow probably looks something like the following: Change the library Publish the library to a local repository Add the local repository to your application's repositories Change your application's dependency to the new library version Test your application Repeat until the problem is fixed or you lose your mind With composite builds, you can short-circuit this workflow by including the library's build into your application's build. Gradle will then automatically replace the binary dependency on the library with a project dependency--meaning that changes you make to the library become available to the application instantaneously: The same approach works for plugins that your project depends on. You can now include a locally checked-out version of a plugin into your project's build and get into the same kind of tight development loop between them: The new includeBuild() API in settings.gradle even lets you write a Gradle build that dynamically