Introduction to Gradle for Beginners

What is Gradle?

Gradle is a build automation tool that supports a lot of languages spanning from Java, C/C++, JavaScript, etc. Gradle was designed for multi-projects structures which can grow very large. It helps us in build, packaging, dependency management(using different buckets like API, implementation, etc.), and publishing.

Before explaining it further let's delve into the advantage that gradle provides on other build tools which is making it so popular.

We have heard of many build tools like Ant, Maven, etc. but Gradle has some of the added flexibility in comparison to the other tools.

Advantages of Gradle over other build tools:

1. Gradle Wrapper allows us to execute Gradle builds even on the machines where Gradle is not installed. It's one of the unique features that Gradle has.

2. It supports incremental builds, if there are some of the projects in a multi-project build structure which did not change, Gradle skips the build of such projects resulting in faster builds. Gradle checks for the task's input and output if any of them have changes only then the task is executed else the task result is returned as "up-to-date".

3. Gradle provides powerful features for multi-project builds and manages the dependencies on its own. The user just needs to define the layout and dependency tree, and the rest of the task is handled by Gradle. If a dependent project is changed, Gradle builds it first and passes on the results to the running project without bothering to run the dependent project.

4. Gradle supports ant and maven repositories from where the dependencies can be fetched.

5. Build Scan is a feature that provides us the complete information of the build runs which even can be shared for the advice required to solve the issues.

6. Gradle is customizable we can customize the logic(tasks) as per our project needs. Gradle provides us a lot of inbuilt useful tasks.

7. We have the option of configuring defaults. This functionality is not present with other build tools.

8. Integration and mitigation from existing Ant/Maven projects are very easy and the projects can be easily converted to the Gradle projects.

Gradle works on the concept of Ant and Maven though but instead of XML, it has introduced the Kotlin or the Domain Specific Language to write down the task.

The task is nothing but the basic unit of execution in Gradle.

Components of Gradle

1. Projects: These can be considered something which is built. It can be formed by the distribution of zip or by the collection of Jars. Every project must contain a build.gradle file which contains the tasks in it. The build.gradle file is the counterpart of pom.xml in Maven and build.xml in Ant.

2. Tasks: It's a single unit of execution in the Gradle build script. It can be the creation of a jar, compile class, copy files, and many other things that one could do with their projects.

3. Plugins: These are the extension of Gradle functionality. Suppose if I want to build a Java project then I can apply the Java plugin in my project's build.gradle file which will give me the access of Java-related tasks defined in the Java Plugin. Gradle is shipped with numerous plugins. We can also develop custom plugins as well.

We can apply the plugin in the following manner apply plugin: 'pluginname'

For example:

apply plugin: 'java' 

Gradle Configurations

Scope in Maven is named as the scope in Gradle. It is suggested to add or apply plugins in a project if we want to get a hold of the configurations.

1. Implementation: It's a default configuration. This dependency is used in compile time and run time but not exposed to our consumers. We can say that the dependency is not exported but its there in the artifact.

2. api: This dependency in this configuration is part of our API and is exposed to our consumers as well. It is present in compile-time, runtime and artifacts as well.

3. compileOnly: The compileOnly dependency is used only at the compile time and is not present at the run time, also, it is not there in the artifact and is never exposed to the consumer.

4. runtimeOnly: The dependency is used only at run time and is not present at compile time, also, it is not there in the artifact and is never exposed to the consumer.

5. testImplementstion: It is similar to the implementation configuration defined above, but dependencies declared with testImplementation are only available during compilation and runtime of tests.

6. testCompileOnly: It is similar to compileOnly, but dependencies declared with testCompileOnly are only available during the compilation of tests and not at runtime.

7. testRuntimeOnly: It is similar to runtimeOnly. It is just that the dependencies defined in this bucket will be available while running the tests and that too at runtime.

Please refer to the example below for defining the dependencies.

dependencies {
    testImplementation 'junit:junit:4.13'
    api 'org.apache.httpcomponents:httpclient:4.5.5'
}