lab3

 Setting Up a Gradle Project - Step-by-Step Instructions

Step 1: Ensure Gradle is Installed

Before starting, verify that Gradle is installed on your Ubuntu system. Open a terminal and run:

gradle -v

If you see version information, you’re set. If not, follow the Gradle installation instructions

from Experiment 1.

Step 2: Create a New Gradle Project

Gradle offers an interactive command to generate a new project using an initialization script.

To create a basic Java application project:

1. Create a new directory for your project and navigate to it:

2. mkdir HelloGradle

3. cd HelloGradle

4. Run the Gradle init command:

5. gradle init --type java-application

You will be prompted to choose between a few options (if you don’t use the non-

interactive mode). Choose defaults or specify details as needed.

Step 3: Explore the Project Structure

After project creation, the directory structure typically looks like this:

HelloGradle/

├── build.gradle

default)

├── gradle/

├── gradlew

├── gradlew.bat

├── settings.gradle

└── src

├── main

│ └── java

└── App.java

└── test

└── java

// The primary build script (Groovy DSL by

// Contains Gradle wrapper files (if generated)

// Unix shell script to run Gradle wrapper

// Windows batch script for Gradle wrapper

// Contains project settings and names

// Your main application source file

└── AppTest.java // Your test cases

Explanation of Components:

• build.gradle:

This is the main build script written in Groovy (or Kotlin if you choose). It defines

plugins, repositories, dependencies, and tasks.

• settings.gradle:

A small script that defines the project’s name and, in multi-project builds, the included

subprojects.

• gradlew

/

gradlew.bat:

The Gradle wrapper scripts. They allow you to run Gradle without requiring a separate

installation on every machine by automatically downloading the correct Gradle version.

• src/main/java:

Contains your application’s source code.

• src/test/java:

Contains your unit tests.

3. Understanding Gradle Build Scripts

A build script in Gradle is a programmatic file that instructs Gradle on how to build your

project. It can be written in two main DSLs:

• Groovy DSL (build.gradle): The traditional and most common syntax.

• Kotlin DSL (build.gradle.kts): A statically-typed alternative that leverages Kotlin’s

language features.

A. Groovy DSL Example (build.gradle)

Below is an example of a basic build.gradle for a Java application using Groovy DSL:

plugins {

// Apply the Java plugin for compiling Java code id 'java'

// Apply the application plugin to add support for building an application

id 'application'

}

group = 'com.example' version

= '1.0'

repositories {

// Use Maven Central for resolving dependencies. mavenCentral()

}

dependencies {

// Define your dependencies. For example, JUnit for testing: testImplementation

'junit:junit:4.13.2'

}

application {

// Define the main class for the application. mainClass =

'com.example.App'

}

// A custom task example: printing a greeting task hello {

doLast {

println 'Hello, Gradle!'

}

}

Explanation:

• plugins block: Declares the plugins used. The java plugin adds Java compilation and

testing tasks, while the application plugin adds tasks for running the application.

• group/version: Sets project coordinates.

• repositories block: Configures the repository (Maven Central) where dependencies

will be resolved.

• dependencies block: Lists the libraries your project depends on.

• application block: Specifies the main class of your application.

• Custom task: Defines a task named hello that prints a greeting when run.

B. Kotlin DSL Example (build.gradle.kts)

Here’s how the same build configuration might look in Kotlin DSL:

Create a file named build.gradle.kts (or convert your file) with the following content:

plugins {

// Apply the Java plugin for compiling Java code java

// Apply the application plugin to add support for building an application

application

}

group = "com.example"

version = "1.0"

repositories {

mavenCentral()

}

dependencies {

// Define dependencies using Kotlin DSL syntax testImplementation("junit:junit:4.13.2")

}

application {

// Set the main class for the application mainClass.set("com.example.App")

}

// A custom task example using Kotlin DSL

tasks.register("hello") {

doLast {

println("Hello, Gradle with Kotlin DSL!")

} }

Explanation:

• Kotlin DSL Syntax: Uses a statically typed syntax, which can be more intuitive for

developers familiar with Kotlin.

• Plugins, Repositories, and Dependencies: Defined similarly to the Groovy DSL but

with Kotlin-style function calls and property access.

• Custom Task Registration: Uses tasks.register to define a task, similar in

functionality to the Groovy DSL.

4. Dependency Management in Gradle

How It Works:

• Repositories: Gradle downloads dependencies from defined repositories (e.g., Maven

Central).

• Dependency Notation: Dependencies are defined in a simple format:

group:artifact:version.

• Configuration Types: Gradle provides various configurations such as implementation,

compileOnly, runtimeOnly, and testImplementation to manage the scope of each

dependency.

Example:

In our build script examples, we included JUnit for testing:

dependencies {

testImplementation 'junit:junit:4.13.2'

}

This line tells Gradle to download JUnit version 4.13.2 from Maven Central and include it in

the test classpath.

Additional Dependency Configurations:

• implementation: Used for dependencies required at compile time.

• runtimeOnly: Used for dependencies required at runtime but not needed for

compilation.

5. Task Automation in Gradle

In Gradle, nearly everything is a task. Tasks represent individual units of work (compiling

code, running tests, packaging applications). Gradle comes with many built-in tasks (provided

by plugins) and allows you to define your own custom tasks.

Built-in Tasks:

• compileJava: Compiles the source code in src/main/java.

• test: Runs tests in src/test/java.

• jar: Packages compiled code into a JAR file.

• run: Runs the application (if the application plugin is applied).

Creating Custom Tasks:

Custom

Task in

Groovy

DSL:

Ensure your build.gradle includes the following custom task:

groovy

CopyEdit task

hello {

doLast {

println 'Hello, Gradle!'

}

}

• Run the Custom Task:

• Command:

gradle hello

• Expected Output:

You should see:

P age 17 | 67

Dept. of CSE

DEVOPS (BCSL657D)

> Task :hello Hello,

Gradle!

• Custom Task in Kotlin DSL (if using build.gradle.kts): Your Kotlin DSL file should include:

tasks.register("hello") { doLast {

println("Hello, Gradle with Kotlin DSL!")

}

}

• Run the Custom Task:

• Command:

./gradlew hello

• Expected Output:

You should see the greeting printed from the custom task.

Task Dependencies:

You can make one task depend on another. For instance, you might want your custom task to

run after the build task:

Groovy DSL:

task greet(dependsOn: build) { doLast {

println 'Build is complete! Time to celebrate!'

}

}

Kotlin DSL:

tasks.register("greet") {

dependsOn("build") doLast {

println("Build is complete! Time to celebrate!")

}

}

Screenshot Tip: Capture your terminal output after running these custom tasks.

6. Running and Verifying Your Gradle Project

Common Gradle Commands:

Build the Project:

Compile, Test, and Package:

• Command:

gradle build

• What it does:

o Compiles source code (compileJava).

o Runs tests (test).

o Packages the application into a JAR file (jar).

• Expected

Output:

Look for a "BUILD SUCCESSFUL" message.

• Screenshot Tip: Capture the full output of the gradle build command

Running the Application

Run the Application:

Command:

gradle run

What it does:

Runs your main class as specified in the application block.

Expected Output:

Any output from your application (for example, if your App.java prints a message).

Executing Custom Tasks

Run the Custom Task:

Command:

gradle hello

Expected Output:

The custom greeting message you defined earlier.

Screenshot Tip: Capture the output showing the greeting. 

Comments

Popular posts from this blog

lab2

lab1

lab4