Gradle
Gradle
|
|
---|---|
Basic data
|
|
Maintainer | Gradle Inc. |
Publishing year | 2007 |
Current version |
6.0 ( November 8, 2019 ) |
operating system | Platform independence |
programming language | Java , Groovy |
category | Build management tool |
License | Apache license, version 2.0 |
gradle.org |
Gradle is a Java- based build management automation tool, comparable to Apache Ant and Apache Maven . Gradle uses a Groovy- based domain-specific language (DSL) to describe the projects to be built. In contrast to Maven project definitions (pom.xml), Gradle scripts are directly executable code.
Gradle is designed for builds of software systems that consist of a variety of projects. Based on the philosophy “expect the unexpected”, an attempt was made to combine the “build-by-convention” principle established in Maven (a variant of “ convention before configuration ”) with the flexibility of Ant.
Large project builds can take a long time to complete. That is why Gradle supports both incremental and parallel build processes. The former enable only those parts of a software to be built that have been changed or are based on changed parts, while the latter allows certain tasks during the build (for example the tests) to run in parallel on several CPUs or computers. This means that the creation process can be made much faster.
Gradle is used by some well-known frameworks for their build - including Hibernate , Grails , Groovy as well as Spring Integration and Spring Security . The Android system has been added since mid-2013 . Since then, the tool has been expanded primarily to support the construction of so-called "native" systems that are not based on the Java platform. The programming languages C ++, C, Objective-C and Assembler are supported here.
Concept and plug-in architecture
Gradle's build concept adopts the standard conventions introduced by Maven ("convention over configuration") for the directory layout of the project sources as well as the usual phases for building a (Java) project (validation, compilation, test execution, archive creation and report generation, Distribution). The build file can therefore be minimal and consist of a single line ( apply plugin: 'java'
) in a simple Java project . Gradle also largely adopts the Maven concept of managing the dependencies of a project on other projects or third-party libraries. Gradle can rely on the widely used Maven repositories (local, corporate and Internet repositories). Alternatively, the user can also fall back on Ivy reports.
Similar to Maven, Gradle consists of an abstract core and a large number of plug-ins and can be expanded in many ways thanks to this structure. Even the implementation of the Java build is based on a plugin for Java. With this architecture Gradle offers the possibility to accomplish build processes for any software platform and gives the user the possibility to bring his "non-conventional" ideas to the tool. Gradle provides plug-ins from the factory that can build Groovy, Scala and C ++ projects in addition to Java . In addition, the build is supported by Java Enterprise Archives (WAR, EAR). Further plug-ins allow the software quality ( e.g. FindBugs , PMD , Checkstyle ) to be monitored through automated checks and the generation of corresponding reports.
The plug-ins supplied with Gradle are mainly made for the development and deployment of Java, Groovy and Scala projects, but they can also be used for other programming languages and workflows. Since the Android team decided to use Gradle as the build system, the developers have mainly been promoting the support of a build model for native programming environments.
Gradle DSL
In contrast to the conventions of Apache Maven and its XML declarations, the user works with Gradle's domain-specific language , which - since a Gradle build file always represents a Groovy script - he can extend or change the standard properties. He can also use Groovy code to write his own build changes or overwrite predefined standards and adapt them to his own needs. Gradle users can use both styles: Maven's declarative approach, based on standard conventions, and Ant's more imperative approach, in which the user has to define everything in detail.
On the basis of this DSL language, the user is not forced to first learn Groovy before attempting Gradle build scripts.
The gradle build
Gradle knows two main phases of build processing that it always goes through: configuration and execution. During the configuration cycle, the entire build definition is run through in order to generate the dependency graph (DAG), which contains the sequence of all steps to be processed. In the second part this graph is run through for the desired tasks. Both the configuration and the execution are accessible to the user through an open API .
The build process, which is described by the task graph, consists of a sequence of tasks that are hierarchically dependent on one another and where a successor is only executed if its predecessors have been successfully completed. For example, the 'test' task is only executed if the 'compile', 'process-resources', 'classes', 'testCompile' tasks have previously been run without errors.
Build files
Gradle mainly uses three custom files for a simple build:
- build.gradle - the definition of the build based on the Gradle DSL with all tasks and dependencies of a project (a multiproject has such a build file per project, which can be kept short by inheriting the properties from its "father" build script) .
- settings.gradle (optional) - in a multiproject, the participating subprojects are specified here.
- gradle.properties (optional) - a list of properties that are valid for the project-specific gradle initialization of a build.
Gradle scripts can contain Groovy code directly or be implemented by a Groovy class. Alternatively, they can be loaded from a Maven repository as a build dependency.
Simple examples for the "build.gradle" file
The simplest build script for a Java project looks like this:
apply plugin: 'java'
Example for defining your own task:
task hello << {
println 'Dies ist der Hello-Task'
}
A task can be called via the command line:
$ gradle hello
IDE support
Gradle plug-ins are available for many integrated development environments , including NetBeans , IntelliJ IDEA and Eclipse . Alternatively, Eclipse and IDEA project files can be generated using Gradle plug-ins.
more details
Apache Ant builds can be replaced by Gradle by importing the build.xml files into Gradle. Ant tasks can also be called directly from the DSL. Gradle can also consume artifacts in Apache Maven repositories as dependencies and also publish artifacts there. Gradle also supports Apache Ivy repositories. With the Build Init Plugin currently under development, Maven projects should be able to be converted to Gradle.
literature
- Tim Berglund, Matthew [J.] McCullough: Building and testing with Gradle . O'Reilly Media, Sebastopol CA 2011, ISBN 978-1-4493-0463-8 .
- Joachim Baumann: Gradle: A compact introduction to the build management system . d.punkt.verlag, 2013, ISBN 978-3-86490-049-5 .
- Benjamin Muschko: Gradle in Action . Manning Publications, 2014, ISBN 978-1-61729-130-2 .
- Hubert Klein Ikkink: Gradle Effective Implementation Guide. Packt Publishing, 2012, ISBN 1-84951-810-6
- Etienne Studer: An introduction to Gradle for Java developers , Gradle will already rock the build and Enterprise Gradle , 3-part series about Gradle in Java Magazine 1 to 3/2011
Web links
Individual evidence
- ↑ Release 6.0 . November 8, 2019 (accessed November 11, 2019).
- ↑ The gradle Open Source Project on Open Hub: Languages Page . In: Open Hub . (accessed on July 18, 2018).
- ↑ The gradle Open Source Project on Open Hub: Licenses Page . In: Open Hub . (accessed on July 18, 2018).
- ↑ Gradle homepage
- ↑ Build Init Plugin