. The execution dependency is in the other direction, as webDist depends on the build artifacts of and hello. There is even a third dependency. webDist has a configuration dependency on date and hello because it needs to know the archivePath. But it asks for this information at execution time. Therefore we have no circular dependency.
Such and other dependency patterns are daily bread in the problem space of multi-project builds. If a build system does not support such patterns, you either can't solve your problem or you need t do ugly hacks which are hard to maintain and massively afflict your productivity as a build master.
49.7. Project lib dependencies
What if one projects needs the jar produced by another project in its compile path? And not just the jar but also the transitive dependencies of this jar? Obviously this is a very common use case for Java multi-project builds. As already mentioned in Section 43.4.3, “Project dependencies”,Gradle offers project lib dependencies for this.
Example 49.24. Project lib dependencies
Build layout
java/
settings.gradle
build.gradle
api/
src/main/java/
org/gradle/sample/
api/
Person.java
apiImpl/
PersonImpl.java
services/personService/
src/
main/java/
org/gradle/sample/services/
PersonService.java
test/java/
org/gradle/sample/services/
PersonServiceTest.java
shared/
src/main/java/
org/gradle/sample/shared/
Helper.java
Note: The code for this example can be found at samples/userguide/multiproject/dep which is in both the binary and source distributions of Gradle.
We have the projects shared, api andpersonService. personService has a lib dependency on the other two projects. api has a lib dependency on shared.
Page 290 of 343
Example 49.25. Project lib dependencies
settings.gradle
include 'api', 'shared', 'services:personService'
build.gradle
subprojects {
apply plugin: 'java'
group = 'org.gradle.sample' version = '1.0' repositories {
mavenCentral()
}
dependencies {
testCompile "junit:junit:4.8.2"
}
}
project(':api') { dependencies {
compile project(':shared')
}
}
project(':services:personService') { dependencies {
compile project(':shared'), project(':api')
}
}
All the build logic is in the build.gradle of the root project. A lib dependency is a special
form of an execution dependency. It causes the other project to be built first and adds the jar with the classes of the other project to the classpath. It also adds the dependencies of the other project to the classpath. So you can enter the api directory and trigger a gradle compile. First shared is built and then api is built. Project dependencies enable partial multi-project builds.
If you come from Maven land you might be perfectly happy with this. If you come from Ivy land, you might expect some more fine grained control. Gradle offers this to you:
Page 291 of 343
Example 49.26. Fine grained control over dependencies
build.gradle
subprojects {
apply plugin: 'java'
group = 'org.gradle.sample' version = '1.0'
}
project(':api') { configurations {
spi
}
dependencies {
compile project(':shared')
}
task spiJar(type: Jar) { baseName = 'api-spi' dependsOn classes
from sourceSets.main.output include('org/gradle/sample/api/**')
}
artifacts { spi spiJar
}
}
project(':services:personService') { dependencies {
compile project(':shared')
compile project(path: ':api', configuration: 'spi') testCompile "junit:junit:4.8.2", project(':api')
}
}
The Java plugin adds per default a jar to your project libraries which contains all the classes. In this example we create an additional library containing only the interfaces of the api project. We assign this library to a new dependency configuration. For the person service we declare that the project should be compiled only against the api interfaces but tested with all classes from api.
49.7.1. Disabling the build of dependency projects
Sometimes you don't want depended on projects to be built when doing a partial build. To disabl the build of the depended on projects you can run Gradle with the -a option.
49.8. Multi-Project Building and Testing
The build task of the Java plugin is typically used to compile, test, and perform code style checks (if the CodeQuality plugin is used) of a single project. In multi-project builds you may often want to do all of these tasks across a range of projects. The buildNeeded and buildDependents tasks can help with this.
Let's use the project structure shown inExample 49.25, “Project lib dependencies”.In this example :services:personservice depends on both :api and :shared. The :api project also depends on
Page 292 of 343
:shared.
Assume you are working on a single project, the :api project. You have been making changes, but have not built the entire project since performing a clean. You want to build any necessary supporting jars, but only perform code quality and unit tests on the project you have changed. The b task does this.
Example 49.27. Build and Test Single Project
Output of gradle :api:build
> gradle :api:build :shared:compileJava :shared:processResources :shared:classes :shared:jar :api:compileJava :api:processResources :api:classes
:api:jar
:api:assemble
:api:compileTestJava
:api:processTestResources
:api:testClasses
:api:test
:api:check
:api:build
BUILD SUCCESSFUL
Total time: 1 secs
While you are working in a typical development cycle repeatedly building and testing changes to the :api project (knowing that you are only changing files in this one project), you may not want to even suffer the expense of :shared:compile checking to see what has changed in the :shared project. Adding the -a option will cause Gradle to use cached jars to resolve any project lib dependencies and not try to re-build the depended on projects.
Page 293 of 343
Example 49.28. Partial Build and Test Single Project
Output of gradle -a :api:build
> gradle -a :api:build :api:compileJava :api:processResources :api:classes
:api:jar
:api:assemble
:api:compileTestJava
:api:processTestResources
:api:testClasses
:api:test
:api:check
:api:build
BUILD SUCCESSFUL
Total time: 1 secs
If you have just gotten the latest version of source from your version control system which included changes in other projects that :api depends on, you might want to not only build all the projects you depend on, but test them as well. The buildNeeded task also tests all the projects from the project lib dependencies of the testRuntime configuration.
Page 294 of 343
Example 49.29. Build and Test Depended On Projects
Output of gradle :api:buildNeeded
> gradle :api:buildNeeded :shared:compileJava :shared:processResources :shared:classes :shared:jar :api:compileJava :api:processResources :api:classes
:api:jar
:api:assemble
:api:compileTestJava
:api:processTestResources
:api:testClasses
:api:test
:api:check
:api:build
:shared:assemble
:shared:compileTestJava
:shared:processTestResources
:shared:testClasses
:shared:test
:shared:check
:shared:build
:shared:buildNeeded
:api:buildNeeded
BUILD SUCCESSFUL
Total time: 1 secs
You also might want to refactor some part of the :api project that is used in other projects. If you make these types of changes, it is not sufficient to test just the :api project, you also need to test all projects that depend on the :api project. The buildDependents task also tests all the projects that have a project lib dependency (in the testRuntime configuration) on the specified project.
Page 295 of 343