1. Wrapper

The gradle wrapper task is a built-in Gradle task that generates the necessary files for the Gradle Wrapper. The Gradle Wrapper is a crucial component for ensuring consistent and reliable builds across different development environments.

When you run the gradle wrapper task (e.g., ./gradlew wrapper or gradle wrapper from your project's root directory), it generates the following files in your project:

1. gradlew (for Unix-like systems) and gradlew.bat (for Windows): These are shell scripts that serve as the entry point for running your Gradle build. Instead of directly executing gradle from your system's installed Gradle, you run these scripts.

2. gradle/wrapper/gradle-wrapper.jar: This is a small JAR file that contains the logic for downloading and invoking the specific Gradle distribution.

3. gradle/wrapper/gradle-wrapper.properties: This file configures the Gradle Wrapper, most importantly specifying the distributionUrl from which to download the Gradle distribution and the gradleVersion to be used for the project.

The main purpose of the Gradle Wrapper is to standardize the Gradle version used for a project and make it easy for anyone to build the project without having Gradle installed globally on their machine. Here are the key benefits:

1. Consistent Builds:

• Guaranteed Version: The wrapper ensures that every developer, CI server, or build environment uses the exact same version of Gradle that the project is designed to work with. This eliminates "it works on my machine" issues caused by different Gradle versions.
• Reproducible Builds: By fixing the Gradle version, you contribute to more reproducible builds, as the build logic will always be executed by the intended Gradle runtime.

2. No Manual Gradle Installation Required:

Developers don't need to manually install Gradle. When you run gradlew for the first time, it automatically downloads the specified Gradle distribution if it's not already present. This simplifies project setup for new team members.

3. Easy Version Upgrades:

To upgrade the Gradle version for your project, you simply update the gradleVersion in gradle/wrapper/gradle-wrapper.properties (or run ./gradlew wrapper --gradle-version ). You then commit these changes to version control, and everyone on the team will automatically use the new version on their next build.

4. Self-Contained Projects:

By committing the wrapper files to your version control system (Git, SVN, etc.), your project becomes self-contained. Anyone who clones the repository can immediately build the project using the wrapper scripts without any additional setup.

gradle-wrapper.jar?

When you run ./gradlew (or gradlew.bat), these scripts simply execute the gradle-wrapper.jar with Java, and then gradle-wrapper.jar takes over the responsibility of ensuring the correct Gradle environment is set up and used for your build.

1. First Run: When you run ./gradlew (or gradlew.bat) for the very first time on a machine for a specific Gradle version, the gradle-wrapper.jar will:

• Read the distributionUrl from gradle/wrapper/gradle-wrapper.properties.
• Download the specified Gradle distribution (e.g., gradle-8.9-bin.zip) from the URL.
• Extract the downloaded distribution into a specific location within your Gradle User Home directory. This directory is typically ~/.gradle on Unix-like systems and C:\Users\.gradle on Windows. The specific path for the distribution will be something like ~/.gradle/wrapper/dists///.

2. Subsequent Runs (Same Version): For all subsequent runs of ./gradlew (or gradlew.bat) with the same Gradle version specified in gradle-wrapper.properties, the wrapper will first check if that specific Gradle distribution already exists in its local cache (~/.gradle/wrapper/dists/).

• If it exists: The wrapper will simply use the locally cached distribution. No download occurs.
• If it doesn't exist (e.g., deleted or on a new machine): It will download it again, as described in the "First Run" scenario.

3. Changing Gradle Version: If you modify the gradleVersion in gradle/wrapper/gradle-wrapper.properties (or run gradle wrapper --gradle-version ), the next time you run the wrapper, it will detect that a different version is required. It will then download and cache this new version. The old version, if still in the cache, will remain there unless Gradle's cache cleanup (which happens periodically) removes it due to disuse.

2. settings.gradle

1. Defines the Build's Root Project:

   Every Gradle build has a single root project. The settings.gradle file is always located in the root directory of your build, and the directory name itself usually serves as the name of the root project.

   rootProject.name = 'server' // You can rename this

2. Declares Subprojects:

   Its primary function is to declare (or "include") the subprojects that constitute your multi-project build. This is done using the include method.

   When you include a directory, Gradle treats it as a subproject and expects to find a build.gradle file within that directory.

   include 'common'
   include 'services:user-service'

3. Configures Project Hierarchy:

   It establishes the hierarchical relationship between projects. You can have nested subprojects, and settings.gradle defines these relationships.

How is it used?

When Gradle runs, Gradle first looks for settings.gradle.
It reads this file to understand the overall structure of your build and identify all the subprojects.
Once the project hierarchy is established, Gradle then proceeds to evaluate the build.gradle files for each of the identified projects (root and subprojects).

3. build.gradle

repositories(): where gradle looks for the libraries

• Maven Central: The most common public repository, hosting a vast collection of open-source libraries.

jar: Jar task creates a jar.

bootJar: The task creates an executable fat jar. For building libraries, bootJar can be enabled = false, since it is not executable.

Tasks

🛠️ Build Lifecycle Tasks

These are the standard tasks you'd run when building a project.

Task	What It Really Does
build	Runs a full build cycle including compile, test, and assemble. Think of it as the “do everything” task.
clean	Deletes the build/ directory. This ensures a fresh start for your next build.
assemble	Compiles and packages the code, but does not run tests.
check	Runs verification tasks like tests and static analysis (e.g., test, lint, etc.).
buildNeeded	Builds the target project and all of its required projects.
buildDependents	Builds the target project and all projects that depend on it.

🔨 Compilation and Packaging Tasks

These tasks are often part of the build lifecycle.

Task	What It Really Does
compileJava	Compiles Java source files under src/main/java.
compileKotlin	(If Kotlin is used) Compiles Kotlin source files under src/main/kotlin.
classes	Assembles compiled classes into the build directory. Depends on compilation tasks.
jar	Packages compiled .class files and resources into a .jar archive.
bootJar	(Spring Boot) Packages an executable fat JAR with dependencies included.
war	Packages the app as a .war (Web Archive), used for Java EE apps.

✅ Testing Tasks

Task	What It Really Does
test	Runs unit tests using the configured test framework (JUnit/TestNG).
testClasses	Compiles test source code.
check	Aggregates all testing and verification tasks.
jacocoTestReport	(If Jacoco plugin is applied) Generates code coverage reports.

📦 Dependency and Publication Tasks

Task	What It Really Does
dependencies	Displays the dependency tree. Useful for debugging conflicts.
dependencyInsight	Shows why a specific dependency is included.
publish	Publishes artifacts to a repository (Maven, Ivy, etc.).
uploadArchives	(Deprecated) Previously used to upload artifacts to a repo.