Gradle

https://docs.gradle.org/current/userguide/userguide_single.html

Great official userguide with walk through examples

Configuration

LINK Configuration is a named set of dependencies grouped together as a specific goal.

Source sets

• the source files and where they’re located

• the compilation classpath, including any required dependencies (via Gradle configurations)

• where the compiled class files are placed

LINK

sourceSet is a placeholder (for main source set it is default)

Dependencies

• Repository => e.g. mavenCentral()

• Configuration => e.g. implementation

• Module coordinate => '<groupId>:<artifactId>:<version>'

Dependency configurations

Every dependency declared for a Gradle project applies to a specific scope. Many Gradle plugins add pre-defined configurations to your project.

Configuration inheritance and composition

Child configurations inherit the whole set of dependencies declared for any of its superconfigurations.

Under the covers the testImplementation and implementation configurations form an inheritance hierarchy by calling the method Configuration.extendsFrom(org.gradle.api.artifacts.Configuration[])

Example

Let’s say you wanted to write a suite of smoke tests. Each smoke test makes a HTTP call to verify a web service endpoint. As the underlying test framework the project already uses JUnit. You can define a new configuration named smokeTest that extends from the testImplementation configuration to reuse the existing test framework dependency.

configurations {
    smokeTest.extendsFrom testImplementation
}

dependencies {
    testImplementation 'junit:junit:4.12'
    smokeTest 'org.apache.httpcomponents:httpclient:4.5.5'
}

Resolvable and consumable configurations

Configurations have at least 3 different roles:

1. to declare dependencies

2. as a consumer, to resolve a set of dependencies to files

3. as a producer, to expose artifacts and their dependencies for consumption by other projects (such consumable configurations usually represent the variants the producer offers to its consumers)

configurations {
    // declare a "configuration" named "someConfiguration"
    // it doesn’t tell us how the configuration is meant to be used
    someConfiguration
}
dependencies {
    // add a project dependency to the "someConfiguration" configuration
    someConfiguration project(":lib")
}

configurations {
    // declare a configuration that is going to resolve the compile classpath of the application
    compileClasspath.extendsFrom(someConfiguration)

    // declare a configuration that is going to resolve the runtime classpath of the application
    runtimeClasspath.extendsFrom(someConfiguration)
}

Api vs Implementation

• api - both a compile and runtime dependency on this artifact

• implementation - only a runtime dependency on this artifact

Good article with explanation

Java plugin

Project layout

LINK

• src/main/java

• src/main/resources

• src/test/java

• src/test/resources

• src/sourceSet/java

• src/sourceSet/resources

Configurations

• Gray text — the configuration is deprecated.

• Green background — you can declare dependencies against the configuration.

• Blue-gray background — the configuration is for consumption by tasks, not for you to declare dependencies.

• Light blue background with monospace text — a task.

Java plugin - main source set dependency configurations

Java plugin - test source set dependency configurations

Java extension

java {
    sourceCompatibility = JavaVersion.VERSION_1_8
    targetCompatibility = JavaVersion.VERSION_1_8
}

Dependency hell

// investigate test class path
gradle -q dependencyInsight --dependency com.h2database --configuration testRuntimeClasspath

gradle -q dependencyInsight --dependency snakeyaml --configuration compileClasspath

// worked recently
gradle etl-core-app:dependencyInsight --dependency databind

Modules

Great article about which kind of modules can exist in the application. LINK

Visualise modules. Tool_1 Tool_2

subprojects vs allprojects

key difference between "subprojects" and "allprojects" is that "subprojects" only applies the settings to the direct subprojects of the current project, while "allprojects" applies the settings to the current project and all of its subprojects.

Build lifecycle

During the configuration phase, Gradle finds the build script(s) in the root and subproject directories.

When a build script, build.gradle(.kts), is found, Gradle configures a Project object.

The purpose of the Project object is to create a collection of Task objects, apply plugins, and retrieve dependencies.

Version catalog

gradle docs