# Gradle

[Great official userguide with walk through examples](https://docs.gradle.org/current/userguide/userguide.html)

## Configuration

[LINK](https://docs.gradle.org/current/userguide/dependency_management_terminology.html#sub:terminology_configuration) 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](https://docs.gradle.org/current/userguide/dependency_management_terminology.html#sub:terminology_configuration))
* where the compiled class files are placed

[LINK](https://docs.gradle.org/current/userguide/building_java_projects.html)

![](/files/-M77CAE3Gevguuqvd6Ii)

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

![](/files/-M77CyiTBeRUXMrevEpd)

## 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.

![](/files/-M77HGJDlLdrpTZ0-Quy)

#### Configuration inheritance and composition

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

![](/files/-M77HewUvg1q3g38Y_4_)

Under the covers the `testImplementation` and `implementation` configurations form an inheritance hierarchy by calling the method [Configuration.extendsFrom(org.gradle.api.artifacts.Configuration\[\])](https://docs.gradle.org/current/dsl/org.gradle.api.artifacts.Configuration.html#org.gradle.api.artifacts.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](https://docs.gradle.org/current/userguide/declaring_dependencies.html#sec:resolvable-consumable-configs) <a href="#sec-resolvable-consumable-configs" id="sec-resolvable-consumable-configs"></a>

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](https://docs.gradle.org/current/userguide/variant_model.html) 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&#x20;

[Good article with explanation](https://tomgregory.com/how-to-use-gradle-api-vs-implementation-dependencies-with-the-java-library-plugin/)

## Java plugin

![](/files/-M77Ej3nOILk9mjiabiB)

### Project layout&#x20;

[LINK](https://docs.gradle.org/current/userguide/java_plugin.html#sec:java_project_layout)

* `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](/files/-M77kZz3SFlArR6Naqc9)

![Java plugin - test source set dependency configurations](/files/-M77wChKaYpCrEm0jwhx)

### 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](https://habr.com/ru/company/cian/blog/667776/)

Visualise modules. [Tool\_1](https://github.com/ivancarras/graphfity) [Tool\_2](https://github.com/savvasdalkitsis/module-dependency-graph)

### 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

<figure><img src="/files/aRUt55gDVOJPXOZp6EPr" alt="" width="375"><figcaption></figcaption></figure>

During the <mark style="background-color:orange;">configuration phase</mark>, 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](https://docs.gradle.org/current/javadoc/org/gradle/api/Project.html) object.

The purpose of the [<mark style="background-color:orange;">Project</mark>](https://docs.gradle.org/current/javadoc/org/gradle/api/Project.html) <mark style="background-color:orange;">object is to create a collection of</mark> [<mark style="background-color:orange;">Task</mark>](https://docs.gradle.org/current/javadoc/org/gradle/api/Task.html) <mark style="background-color:orange;">objects, apply plugins, and retrieve dependencies</mark>.

## Version catalog

[gradle docs](https://docs.gradle.org/current/userguide/platforms.html)


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://amartyushov.gitbook.io/tech/tools/gradle.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.