Coding With Fun
Home Docker Django Node.js Articles Python pip guide FAQ Policy

Gradle Overview


May 25, 2021 Gradle


Table of contents


Overview

Description of the feature

Below is a list of some Gradle features.

Claims-based and convention-based builds

At the heart of Gradle is Groovy's rich and scalable domain description language (DSL). G roovy pushes claims-based builds down to the lower levels with declarative language elements, which you can combine the way you want. T hese elements also provide convention-based builds to support Java, Groovy, OSGi, Web, and Scala projects. A lso, this declarative language can be extended. Y ou can add new or enhanced existing language elements. A s a result, it provides concise, maintainable, and easy-to-understand builds.

Provides language support for dependency-based programming

The advantage of declarative language is that it is a generic task diagram that you can take full advantage of in the build. It provides maximum flexibility to adapt Gradle to your specific needs.

Build structured

Gradle's flexibility and richness ultimately support the application of common design patterns in your build. F or example, it can easily split your build into reusable modules and then assemble them, but don't force the modules to split. D on't force the things that were together (such as in your project structure) to avoid turning your build into a nightmare. Finally, you can create a well-structured, easy-to-maintain, easy-to-understand build.

Depth API

Gradle allows you to monitor and customize its core configuration and execution behavior throughout the lifecycle of build execution.

Gradle's extension

Gradle has very good scalability. F rom simple single-project builds to massive multi-project builds, it can significantly increase your efficiency. T hat's the real structured build. With state-of-the-art incremental build capabilities, it solves performance bottlenecks faced by many large enterprises.

Multi-project build

Gradle's support for multi-project building is excellent. P roject dependency is the first thing to consider. W e allow you to model project dependencies in multi-project builds because they are your real problem domain. Gradle follows your layout.

Gradle provides the ability to build locally. I f you're building a separate sub-project, Gradle will also help you build all the sub-projects on which it depends. Y ou can also choose to rebuild sub-projects that depend on specific sub-projects. This incremental build will save a lot of time in large build tasks.

There are several ways to manage dependencies

Different teams like to manage their external dependencies in different ways. From the delivery-dependent management of Maven and Ivy's remote repositories to the jar packages or directories of the local file system, Gradle provides convenient support for all management policies.

Gradle was the first to build an integration tool

Ant tasks are the most important. M ore interestingly, Ant projects are also the most important. G radle provides a deep import of any Ant project and converts the Ant target to a native Gradle task at runtime. Y ou can rely on them (Ant targets) from Gradle, enhance them, and even define .xml Gradle tasks on your build. Gradle provides the same integration for properties, paths, and so on.

Gradle fully supports Maven or Ivy repositories for publishing or retrieving dependencies. G radle also provides a converter for converting a Maven pom .xml file into a Gradle script. The functionality imported at the runtime of the Maven project will be expected soon.

Easy to port

Gradle adapts to any structure you already have. A s a result, you can always develop your Gradle build scripts in the same branch of your build project, and they work in parallel. W e usually recommend writing tests to ensure that the resulting files are the same. T his migration is as reliable and less destructive as possible. This is also a best practice for refactoring.

Groovy

Gradle's build script was written in Groovy, not XML. B ut unlike other methods, it doesn't just show the power of original scripts written in a dynamic language. T hat would make it difficult to maintain the build. G radle's overall design is oriented towards being a language, not a rigid framework. A nd Groovy is the glue that allows you to describe your personal story through abstract Gradle. G radle provides some common-standard story. T his is a key feature of our declarative build system compared to other. O ur Groovy support isn't a simple sugar coat, and the entire Gradle API is completely groovy. Only Groovy can use it and make it more efficient.

The Gradle wrapper

Gradle Wrapper allows you to perform Gradle builds on machines that do not have Gradle installed. T his is very useful. F or example, for some continuous integration services. I t is also useful for building an open source project with a low threshold. W rapper is also useful for businesses, making it zero-configuration for client computers. It enforces the specified version to reduce compatibility support issues.

Free and open source

Gradle is an open source project and follows the ASL license.

Why Groovy?

We think internal DSLs (based on a dynamic language) have a big advantage over XML in building scripts. T hey are a pair of dynamic languages. W hy Groovy? T he answer lies in the operating environment within Gradle. A lthough Gradle's core purpose is to be a common build tool, it is primarily for Java projects. T eam members on these projects are clearly familiar with Java. We believe that a build tool should be as transparent to all team members as possible.

You might want to say why you can't use Java as the language for building scripts. I think this is a very meaningful question. F or your team, it does have the highest transparency and the lowest learning curve. H owever, due to the limitations of Java itself, this build language may not be as friendly, expressive, and powerful. T hat's why languages like Python, Groovy, or Ruby do better in this regard. W e chose Groovy because it provides Java people with the greatest transparency to date. I ts basic syntax, type, package structure, and other aspects are just like Java, and Groovy adds a lot more to it. But it also has something in common with Java.

This argument does not apply to Java teams that share and are happy to learn about Python. G radle is designed to create another build script engine in JRuby or Jython. A t that time, for us, it was just no longer the highest priority. We're excited to support any community effort to create additional build script engines.