Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Fixed images to be included and not links

Gradle build files are written using Apache Groovy.

Table of Contents

Gradle Dependency Configuration

ColorPurpose
Gray TextRemoved in Gradle 7.0
Light GreenUsed to declare dependencies
Blue GrayConsumed by tasks to create dependency set/classpath
Light BlueTask

Main source set

Image Added


Test source set

Image Added

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 build
  • tasks: Displays tasks runnable from the root project (including those in subprojects)
  • dependencies: Displays dependencies for a project, for each configuration scope
  • dependencyInsight --dependency <name> --configuration <name>: Inspect why a dependency exists for a project configuration
  • properties: Print the properties of a configured project
  • help --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
languagegroovy
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
languagebash
./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
languagegroovy
firstline1
linenumberstrue
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) {
  ...}