"Reprint" Gradle Study Chapter II: Overview

Reprint Address: HTTP://ASK.ANDROID-STUDIO.ORG/?/ARTICLE/6

Here is a list of some of Gradle ' s features.
< translation > The following is a description of Gradle features

Declarative builds and Build-by-convention Declaration and convention
At the heart of Gradle lies a rich extensible Domain specific Language (DSL) based on Groovy. Gradle pushes declarative builds to the next level by providing declarative language elements so can assemble as you Like. Those elements also provide build-by-convention support for Java, Groovy, OSGi, Web and Scala projects. Even more, this declarative language is extensible. Add your own new language elements or enhance the existing ones, thus providing concise, maintainable and comprehensible B Uilds.
< translation The core of >gradle is a rich and extensible groovy-based domain-specific language (DSL). Gradle you can assemble by providing descriptive language elements that push the descriptive build to the next level. These elements also provide build-by-convention support for Java, Groovy, OSGi, Web, and Scala projects. More, this descriptive language is extensible. Add your own new language elements or improve existing ones to provide simplicity, ease of maintenance, and understanding of the build.

Language for dependency based programming dependent programming language
The declarative language lies on top of a general purpose task graph, which you can fully leverage in your builds. IT provides utmost flexibility to adapt Gradle to your unique needs.
< translation > Descriptive language is on the list of common tasks, all of which you can make full use of in the project. It offers maximum flexibility to suit your unique needs for gradle.

Structure Your build Build your project
The suppleness and richness of Gradle finally allows you to apply common design principles to your build. For example, it's very easy-to-compose your build from reusable pieces of build logic. Inline stuff where unnecessary indirections would be inappropriate. Don ' t be forced to tear apart what belongs together (e.g. in your project hierarchy). Avoid smells like shotgun changes or divergent change, turn your build into a maintenance nightmare. At last you can create a well structured, easily maintained, comprehensible build.
< translation >

Deep API in-depth interface
From being a pleasure to being used embedded to it many hooks over the whole lifecycle of build execution, Gradle allows To monitor and customize their configuration and execution behavior to its very core.
< translation >

Gradle Scales
Gradle scales very well. It significantly increases your productivity, from simple single project builds up to huge enterprise multi-project builds . This is true for structuring the build. With the State-of-art incremental build function, this is also true for tackling the performance pain many large enterpris E builds suffer from.
< translation >

Multi-Project builds
Gradle ' s support for multi-project build is outstanding. Project dependencies is first class citizens. We allow you to model the project relationships in a multi-project build as they really is for your problem domain. Gradle follows your layout not vice versa.
< translation >

Gradle provides partial builds. If you build A, subproject Gradle takes care of building all the subprojects, subproject on. You can also choose to rebuild the subprojects that depend on a particular subproject. Together with incremental builds-a big time saver for larger builds.
< translation >gradle provides the construction of a local project.

Many ways to manage your dependencies multiple ways to manage your engineering build dependencies
Different teams prefer Different ways to manage their external dependencies. Gradle provides convenient support for any strategy. From transitive dependency management with remote Maven and Ivy repositories to jars or directories on the local file Syst Em.
< translation > Different teams like to manage the external dependencies of the project in different ways. Gradle provides support for different management strategies. The jar packages or directories from the dependency management and remote Maven and Lvy libraries to the local file system are included.

Gradle is the first build integration tool Gradle
Ant tasks is first class citizens. Even more interesting, Ant projects is first class citizens as well. Gradle provides a deep import for any Ant project, turning ant targets to native Gradle tasks at runtime. You can depend on them from Gradle, you can enhance them from Gradle, you can even declare dependencies on Gradle tasks in Your build.xml. The same integration is provided for properties, paths, etc ...
< translation >

Gradle fully supports your existing Maven or Ivy repository infrastructure for publishing and retrieving dependencies. Gradle also provides a converter for turning a Maven pom.xml into a Gradle script. Runtime imports of Maven projects'll come soon.
< translation >

Ease of migration facilitates migration
Gradle can adapt to any structure you have. Therefore you can all develop your Gradle build in the same branch where your production build lives and both can Evolv E in parallel. We usually recommend to write tests this make sure that the produced artifacts is similar. That's the migration is as less disruptive and as reliable as possible. This was following the best-practices for refactoring by applying baby steps.
< translation >gradle applies to any of your engineering structures.

Groovy
Gradle ' s build scripts is written in Groovy, not XML. But unlike and other approaches this is not for simply exposing the raw scripting power of a dynamic language. That would just leads to a very difficult to maintain build. The whole design of Gradle is oriented towards being used as a language, not as a rigid framework. And Groovy is our glue this allows you to tell your individual stories with the abstractions Gradle (or you) provide. Gradle provides some standard stories but they is not privileged in any form. This was for us a major distinguishing feature compared to other declarative build systems. Our Groovy support isn't just sugar coating. The whole Gradle API is fully groovy-ized. Adding Groovy results in an enjoyable and productive experience.
< translation >

The Gradle wrapper Gradle outer
The Gradle Wrapper allows you to execute Gradle builds on machines where Gradle are not installed. This is useful for example for some continuous integration servers. It is also useful for a open source project to keep the barrier low for building it. The wrapper is also very interesting for the enterprise. It's a zero administration approach for the client machines. It also enforces the usage of a particular Gradle version thus minimizing support issues.
< translation >

Free and open source freeware and open source
Gradle is a open source project, and is licensed under the ASL.
< translation >

2.2. Why Groovy? Reasons to use Groovy
We think the advantages of an internal DSL (based to a dynamic language) over XML is tremendous when used in build script S. There is a couple of dynamic languages out there. Why Groovy? The answer lies in the context Gradle are operating in. Although Gradle is a general purpose build tool at its core, it main focus is Java projects. In such projects, the team members would be very familiar with Java. We think a build should is as transparent as possible to all team members.
< translation >

In this case, you might argue why we don ' t just use Java as the language for build scripts. We think this is a valid question. It would has the highest transparency for your team and the lowest learning curve, but because of the limitations of Java , such a build language would not being as nice, expressive and powerful as it could be. [1] Languages like Python, Groovy or Ruby does a much better job here. We have chosen Groovy as it offers by far the greatest transparency for Java people. Its-base syntax is the same as Java's as well as it type system, its package structure and other things. Groovy provides much more on top of this, but with the common foundation of Java.
< translation > as such

For Java developers with Python or Ruby knowledge or the desire to learn them, the above arguments don ' t apply. The Gradle design is well-suited-creating another build script engine in JRuby or Jython. It just doesn ' t has the highest priority for us at the moment. We happily support any community effort to create additional build script engines.
< translation > For Java Developers, the above narrative does not apply to learning the knowledge of the Pythen language or the Ruby language or using them for development. Gradle is designed for another scripting engine that is developed for use with JRuby or Jython. It's just that we didn't give it the highest priority at the beginning of the design. We are happy to create more scripting engines by exploiting the power of the community.

Original address: Http://www.gradle.org/docs/cur .... Html
Translated by: Pfei_he
Email: [email protected]

If you have any objection to the translation, please submit or contact the author in the comment area.

"Reprint" Gradle Study Chapter II: Overview