Difference between revisions of "Gradle"

(Created page with " Gradle link: [https://gradle.org/ https://gradle.org/]")
 
Line 1: Line 1:
 +
Gradle is a dependency management and a build automation tool which was built upon the concepts of Ant and Maven.
 +
 +
Gradle combines good parts of both tools and builds on top of them with DSL and other improvements. It has Ant’s power and flexibility with Maven’s life-cycle and ease of use. The end result is a tool that was released in 2012 and gained a lot of attention in a short period of time. For example, Google adopted Gradle as the default build tool for the Android OS.
 +
 +
Gradle does not use XML. Instead, it had its own DSL based on Groovy (one of JVM languages). As a result, Gradle build scripts tend to be much shorter and clearer than those written for Ant or Maven. The amount of boilerplate code is much smaller with Gradle since its DSL is designed to solve a specific problem: move software through its life cycle, from compilation through static analysis and testing until packaging and deployment.
 +
 +
Initially, Gradle used Apache Ivy for its dependency management. Later own it moved to its own native dependency resolution engine.
 +
 +
 +
Over time, developers became more and more interested in having and working with a domain specific language – which, simply put, would allow them to solve problems in a specific domain using a language tailored for that particular domain.
 +
 +
This was adopted by Gradle, which is using a DSL based on Groovy. This led to smaller configuration files with less clutter since the language was specifically designed to solve specific domain problems. Gradle’s configuration file is by convention called build.gradle.
 +
 +
Here is an example of a build.gradle file for the same simple Java project with the HelloWorld main class from before:
 +
 +
<source>
 +
 +
apply plugin: 'java'
 +
 +
repositories {
 +
    mavenCentral()
 +
}
 +
 +
jar {
 +
    baseName = 'gradleExample'
 +
    version = '0.0.1-SNAPSHOT'
 +
}
 +
 +
dependencies {
 +
    compile 'junit:junit:4.12'
 +
}
 +
 +
</source>
 +
 +
We can compile the code by running:
 +
 +
<source>
 +
 +
gradle classes
 +
 +
</source>
 +
 +
At its core, Gradle intentionally provides very little functionality. Plugins add all useful features. In our example, we were using java plugin which allows us to compile Java code and other valuable features.
 +
 +
Gradle gave its build steps name “tasks”, as opposed to Ant’s “targets” or Maven’s “phases”. With Maven, we used Apache Maven Dependency Plugin, and it’s specific goal to copy dependencies to a specified directory. With Gradle, we can do the same by using tasks:
 +
 +
<source>
 +
 +
task copyDependencies(type: Copy) {
 +
  from configurations.compile
 +
  into 'dependencies'
 +
}
 +
 +
</source>
 +
We can run this task by executing:
 +
 +
<source>
 +
 +
gradle copyDependencies
 +
 +
</source>
 +
 +
 +
Gradle effort can be summed as “convention is good and so is flexibility”.
 +
 +
 +
 +
 +
  
 
Gradle link: [https://gradle.org/ https://gradle.org/]
 
Gradle link: [https://gradle.org/ https://gradle.org/]

Revision as of 07:00, 3 June 2018

Gradle is a dependency management and a build automation tool which was built upon the concepts of Ant and Maven.

Gradle combines good parts of both tools and builds on top of them with DSL and other improvements. It has Ant’s power and flexibility with Maven’s life-cycle and ease of use. The end result is a tool that was released in 2012 and gained a lot of attention in a short period of time. For example, Google adopted Gradle as the default build tool for the Android OS.

Gradle does not use XML. Instead, it had its own DSL based on Groovy (one of JVM languages). As a result, Gradle build scripts tend to be much shorter and clearer than those written for Ant or Maven. The amount of boilerplate code is much smaller with Gradle since its DSL is designed to solve a specific problem: move software through its life cycle, from compilation through static analysis and testing until packaging and deployment.

Initially, Gradle used Apache Ivy for its dependency management. Later own it moved to its own native dependency resolution engine.


Over time, developers became more and more interested in having and working with a domain specific language – which, simply put, would allow them to solve problems in a specific domain using a language tailored for that particular domain.

This was adopted by Gradle, which is using a DSL based on Groovy. This led to smaller configuration files with less clutter since the language was specifically designed to solve specific domain problems. Gradle’s configuration file is by convention called build.gradle.

Here is an example of a build.gradle file for the same simple Java project with the HelloWorld main class from before:

apply plugin: 'java'
 
repositories {
    mavenCentral()
}
 
jar {
    baseName = 'gradleExample'
    version = '0.0.1-SNAPSHOT'
}
 
dependencies {
    compile 'junit:junit:4.12'
}

We can compile the code by running:

gradle classes

At its core, Gradle intentionally provides very little functionality. Plugins add all useful features. In our example, we were using java plugin which allows us to compile Java code and other valuable features.

Gradle gave its build steps name “tasks”, as opposed to Ant’s “targets” or Maven’s “phases”. With Maven, we used Apache Maven Dependency Plugin, and it’s specific goal to copy dependencies to a specified directory. With Gradle, we can do the same by using tasks:

task copyDependencies(type: Copy) {
   from configurations.compile
   into 'dependencies'
}

We can run this task by executing:

gradle copyDependencies


Gradle effort can be summed as “convention is good and so is flexibility”.




Gradle link: https://gradle.org/