Gradle Concepts TO DEPLETE

DEPLETE INTO

Gradle Concepts

Artifacts and Artifact Publishing

A Gradle project produces artifacts, which are the files the project provides to the outside world. An artifact may be built locally by a plugin such as the Application plugin, which in turn delegates the artifact building part to Distribution plugin, or by other plugins. This creates the artifact locally, in the project build area. More details about how to configure artifact generation is available in:

Gradle Artifacts

In most cases, we want these artifacts to be pushed to external repositories, as described here:

Gradle Artifact Publishing Concepts

Module

A module is a piece of software that evolves over time. Every module has a name, and each release of a module is identified by a module version. Modules can be hosted in repositories. Modules usually are described by module metadata, which is information associate with a module. Metadata includes coordinates for locating the module in a repository (group ID, artifact name and version), information about the module's transitive dependencies, authors, etc. In Maven, the metadata file is called POM. This is an example of module metadata published into a Maven repository by a "playground.b:b:1.0" module that depends on "playground.a:a:1.0" module:

<?xml version="1.0" encoding="UTF-8"?>
<project xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 
    http://maven.apache.org/xsd/maven-4.0.0.xsd" 
    xmlns="http://maven.apache.org/POM/4.0.0"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
  <modelVersion>4.0.0</modelVersion>
  <groupId>playground.b</groupId>
  <artifactId>b</artifactId>
  <version>1.0</version>
  <dependencies>
    <dependency>
      <groupId>playground.a</groupId>
      <artifactId>a</artifactId>
      <version>1.0</version>
      <scope>runtime</scope>
    </dependency>
  </dependencies>
</project>

A module version is a label that designates a distinct set of changes released as a unit. The most widely-used versioning strategy is semantic versioning.

The Gradle Wrapper

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

Gradle Wrapper is the recommended way to execute a Gradle build. The Wrapper is a script that invokes a declared version of Gradle, downloading it beforehand if necessary.

./gradlew ...

The wrapper caches the appropriate Gradle runtime under $USER_HOME/.gradle/wrapper/dists/. Using the wrapper effectively locks a specific Gradle version to the project. One of the advantages of using the Gradle wrapper is that other people that attempt to build the project do not have to have Gradle installed on their system, everything Gradle needs to run comes with the wrapper. If the code is build with AWS CodeBuild and the image used for building does not have gradle installed, or it has an older version, building the project with gradlew is an immediate solution.

Gradle Wrapper Initialization

Per-project graddle wrapper infrastructure can be created with gradle init. Spring Initializr also creates wrapper scripts during the process of Spring project initialization. For a project already operational, gradle init will detect build.gradle and it will bail out. For such situations, create a temporary directory, gradle init it, and move gradle and gradlew into the Gradle project:

mkdir tmp
cd tmp
gradle init
mv gradle gradlew <target-gradle-project>

Gradle Version

Gradle Version

The Gradle Daemon

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

Configured with "org.gradle.daemon" and "org.gradle.daemon.idletimeout" Gradle property. On by default.

Build Caching

Build Caching