Gradle build files are written using Apache Groovy.
Table of Contents |
---|
Gradle Dependency Configuration
Color | Purpose |
---|---|
Gray Text | Removed in Gradle 7.0 |
Light Green | Used to declare dependencies |
Blue Gray | Consumed by tasks to create dependency set/classpath |
Light Blue | Task |
Main source set
Test source set
Note that the testRuntimeConfiguration was added to the default set of Java Gradle configurations to simulate the testRuntime configuration by Gradle 6.x and earlier.
Gradle Tests Parallelization
The build is configured to run on a given number of workers that are responsible for all the tasks of the build (running tests, compiling code, checkstyle, findbugs, ...)
...
Gradle targets can be specified with either the project name or directory, for example:
$ ./gradlew :beam-website:serveWebsite
is the same as
...
The mapping of directory to project name is in settings.gradle
Code Coverage
Because of issues with the Jacoco plugin, it is disabled unless explicitly requested. And if you request a report, you must also request the tests to report on, like so:
./gradlew -p sdks/java/extensions/sql test jacocoTestReport
Troubleshooting build issues
...
There are also various built-in tasks useful for introspecting components of the build:
projects
: Lists all projects in present in the buildtasks
: Displays tasks runnable from the root project (including those in subprojects)dependencies
: Displays dependencies for a project, for each configuration scopedependencyInsight --dependency <name> --configuration <name>
: Inspect why a dependency exists for a project configurationproperties
: Print the properties of a configured projecthelp --task <taskName>
: Display help message for a specific task.
Visualizing Task Dependencies
Our build uses the gradle-task-tree plugin to visualize execution graph task dependencies during the build. This makes it easy to inspect why a task was included and ordering constraints.
To produce a dependency graph, invoke Gradle with a set of tasks and include taskTree
from the same project (i.e. ./gradlew :beam-sdks-java-core:build :beam-sdks-java-core:taskTree). Instead of executing the tasks, the gradle-task-tree plugin will print out an ASCII dependency tree on the commandline.
Troubleshooting Resources
...
./gradlew -PgcpProject=myGoogleCloudProject -PgcsBucket=myGoogleCloudStorageBucket \:beam-runners-:google-cloud-dataflow-java-:examples:preCommit
Setting build customizations in a user config file
...
initscript {
repositories {
gradlePluginPortal()
}
dependencies {
classpath 'com.gradle:build-scan-plugin:12.134.12'
}
}
rootProject {
apply plugin: com.gradle.scan.plugin.BuildScanPlugin
buildScan {
publishOnFailure()
termsOfServiceUrl = 'https://gradle.com/terms-of-service'
termsOfServiceAgree = 'yes'
}
}
...
Code Block |
---|
./gradlew -Ppublishing --no-parallel -PdistMgmtSnapshotsUrl=~/.m2/repository/ -p sdks/java/io/kafka publishpublishToMavenLocal |
If the local maven repository isn't in the default path of ~/.m2/repository/
then it can be replaced with a custom path like the following: file:///path/to/custom/maven/repo
Once a snapshot version of Beam has been built, you must depend on that snapshot when running pipelines. See the snippet below for an example of how to use the snapshot as a dependency in Gradle. For more info seethe Gradle documentation.
Code Block | ||
---|---|---|
| ||
repositories {
maven {
url "file:///path/to/custom/maven/repo"
} // Use this when using a non-default local repo.
mavenLocal() // Use this with the default local repo.
mavenCentral()
}
dependencies {
implementation "org.apache.beam:beam-sdks-java-io-kafka:2.23.0-SNAPSHOT"
} |
Publish a vendored dependency locally
Code Block | ||
---|---|---|
| ||
./gradlew -p vendor/bytebuddy-1_10_8 -PisRelease -Psigning.gnupg.keyName=apache.org -PvendoredDependenciesOnly publishToMavenLocal |
You can find this and more details in the vendored dependencies release guide.
Copying Test Resources Across Gradle Projects
For tests run in one project (e.g. integration tests run by :sdks:java:io:google-cloud-platform
) that run tests defined in another (e.g. :runners:google-cloud-dataflow-java
) your tests may depend on resources (canonically in src/test/resources
of that source tree).
To add these files to the build.gradle
to include a copy task to get files from one project to another.
Code Block | ||||||
---|---|---|---|---|---|---|
| ||||||
task copyGoogleCloudPlatformTestResources(type: Copy){
from project(':sdks:java:io:google-cloud-platform').fileTree("src/test/resources")
into "$buildDir/resources/test/"
}
task googleCloudPlatformLegacyWorkerIntegrationTest(type: Test, dependsOn: copyGoogleCloudPlatformTestResources) {
...} |