We get rid of binary dependencies with composite assembly in Gradle 3.1

From the very beginning of Gradle, there were 2 ways to split your assembly into components: through binary dependencies and using multi-project assembly. Each of these methods has its pros and cons. In the case of binary dependencies, it becomes necessary to publish artifacts, which complicates assembly. In the case of multi-project assembly, it becomes
more difficult to isolate components from each other.

Composite assemblies

In the upcoming version 3.1 in Gradle, a new approach to organizing assemblies consisting of several components appears: composite assemblies ( original Composite Builds).

Composite assemblies allow you to:

• Quickly put the corrected version of the source code of the library into another project without having to build it, publish and edit the build.
• To divide large projects into several small, isolated assemblies, on each of which you can work both individually and simultaneously.
• Separate plugin development for the build system from the project that uses it (similar to buildSrc )

Let us analyze a simple example of using a new feature.

To do this, create a simple project:

 --app/ |-src/main/java/Main.java |-build.gradle - lib/ |-src/main/java/A.java |-build.gradle |-settings.gradle 

lib / build.gradle:

 apply plugin: 'java' group "ru.shadam" version "1.0" task wrapper(type: Wrapper) { gradleVersion = '3.1-rc-1' } 

app / build.gradle

 apply plugin: 'java' apply plugin: 'application' mainClassName='Main' dependencies { compile 'ru.shadam:lib1:1.0' } task wrapper(type: Wrapper) { gradleVersion = '3.1-rc-1' } 

Now, if we try to start the app using the command ./gradlew run Gradle will swear at an unresolved dependency:

 $ ./gradlew run :compileJava FAILURE: Build failed with an exception. * What went wrong: Could not resolve all dependencies for configuration ':compileClasspath'. > Cannot resolve external dependency ru.shadam:lib1:1.0 because no repositories are defined. Required by: project : * Try: Run with --stacktrace option to get the stack trace. Run with --info or --debug option to get more log output. BUILD FAILED Total time: 1.027 secs 

But, if we add a new flag - include-build, then Gradle will automatically resolve dependencies:

 $ ./gradlew run --include-build ../lib1 [composite-build] Configuring build: C:\Users\sala\projects\gradle-compose\lib1 :compileJava :lib1:compileJava UP-TO-DATE :lib1:processResources UP-TO-DATE :lib1:classes UP-TO-DATE :lib1:jar UP-TO-DATE :compileJava UP-TO-DATE :processResources UP-TO-DATE :classes UP-TO-DATE :run Hello BUILD SUCCESSFUL Total time: 1.092 secs 

Advanced use cases.

We build --include-build into a script

The above option is more suitable for one-time use - here and now. Each time you do not want to specify the flags - even if you sew them in a wrapper.

For this, gradle suggests using a configuration using settings.gradle. So, the above flag can be replaced with the following settings.gradle:

 includeBuild('../lib1') 

Substitutions

What if in the project that you want to include are not listed coordinates of the artifact? (group, version)

The substitutions come to the rescue:

 includeBuild('../lib1') { dependencySubstitution { substitute('ru.shadam:lib1') with project(':') } } 

This feature allows you to substitute any dependency on ru.shadam:lib1 dependency on the lib1 project.

Dependencies between tasks

In the case of a composite assembly, projects are isolated from each other, so you cannot declare dependencies between assemblies directly.

In this regard, a new syntax for accessing the included assemblies has appeared. For example, you can define a dependency on the task of the included build:

  task run { dependsOn gradle.includedBuild('lib1').task(':jar') } 

What is not working yet?

• Projects that have published artifacts that do not conform to the default configuration are not supported as included projects. link
• Currently there is no support in IDE (but project generation is supported using the ./gradlew idea command)
• Native builds are not supported.

Team plans

• Add the ability to call tasks directly from included builds.
• Add the ability to simultaneously run the included assembly
• Add detection of changes to included builds when the -t flag is used.
• Make an implicit buildSrc project included in the build.

Used materials

• Documentation
• Repository with examples