Hello there, welcome to my new series of blog posts on the Gradle build system. Today, I chose to write on the Gradle because, to most of the new android app developers, Gradle is a block box, and they get easily confused about its working and syntax. As Gradle is the default build tool for building an android application, we should know how it works to make our life better.
In this series of blog posts, I am going to cover essential things related to the Gradle build tool, which will help you to understand the working of Gradle. Before diving deep into the Gradle world, let’s know the basic things first.
Why Do We Need a Build Automation Tool?
The most common processes in building any software include compiling the source code, packaging the compiled output to a compressed format like apk(android), JAR, TAR, ZIP, etc. Along with this, we might also perform some other tasks like run the static code analysis or execute the tests on the source code or publish the artifacts to some repository.
Now imagine if there is no build tool to automate this process; then, we will need to perform all of these actions manually. But following are the problems with the manual system:
People get bored by doing the same things again and again.
Also, there are chances of human errors; for example, we might forget to supply some required input parameters, or we might forget to execute some intermediate step.
Maintaining the order of task is hard, as most of the actions are dependent on the output of some other task; for example, before creating a jar we need to compile the source code.
Build automation allows us to automate the manual steps involved in the build process. It saves the cost and time spent in the manual process. The main goal of the build automation tool is to create reproducible assets every time we run the build script. As now we know the importance of the build tools, let’s get more information about them.
Types Of Build Tools:
There are two types of build tools, imperative and declarative build tools. An imperative build tool tells the system what to do and how to do it. It means to the imperative build system, we need to specify all steps involved in the build process. Along with specifying each step, we also need to provide information about how to execute those steps. Ant is an example of an imperative build tool.
On the other hand, for declarative tools, we only need to specify what we would like to achieve, and the system will figure out how to do it. Maven is an example of the declarative build tool. Now, You might be wondering, where does Gradle fit in between them?
What Is a Gradle?
Gradle is a general-purpose, declarative build tool. It combines the good parts of both Ant(imperative) and Maven(declarative) tools and provides additional features.
We can use either Groovy or Kotlin to write a build script to provide instructions to Gradle. In this series, we are going to use Kotlin language to write our build scripts. To migrate your existing build script written in the Groovy to Kotlin refer to this official link.
Primarily, Gradle is a JVM-language build tool, but it also supports writing build tool for C, C++ and so on.
# Gradle Vs. Continuous Integration (CI):
Do not get confused between Gradle and CI. CI helps to create a workflow for build and deployment automation. It also helps to schedule the builds and provides on-demand execution of builds. Some of the well known CI tools are Jenkins, TeamCity, Bamboo, Hudson, Cruise Control, and so on, which are different from Build tools, such as Ant, Maven, and Gradle. Right?
Features of Gradle:
Following are the few cool features that Gradle provides:
- Incremental Build
Gradle Build is composed of several tasks, and task may take some inputs and produce some outputs. Gradle checks whether the input, output or implementation of a task has changed since the last build invocation. If not, the task is considered up to date and is not executed, which results in faster build completion.
- Parallel Execution
Gradle allows parallel execution of tasks, which also helps in reducing the build time.
- Build Output Caching
Gradle can cache the outputs of the build. An advantage of the caching is that — we can reuse the cached output to build some other task, which is dependent on it. This will avoid the expensive work of regenerating them.
The typical use case is to let CI build push to a shared build cache and allow developers to pull from it.
- Task Exclusion
We often need to run some tasks depending on some conditions. And when we exclude a task, all tasks this task depends on are also automatically excluded if they have no other dependencies. We can also mention the task name which we want to exclude using the -x, or --exclude-task option from command line.
- Dry Run
We can use this feature to make sure that all the configuration for the build scripts are ok. In dry run, Gradle will not execute the task actions.
Use -m or --dry-run option to run build script in dry run mode.
- Version Conflict Resolution
Sometime in a multi-project build, there might come a situation where more than one project has a common dependency. In this case, Gradle resolves the dependency conflicts by using the newest requested version. We can also customize this behavior.
- Transitive Dependencies
One of the main benefits of using a dependency management system is managing transitive dependencies. Gradle takes care of downloading and managing transitive dependencies.
- Continue Execution After Failures
By default, Gradle build execution stops as soon as the first task fails. But, sometime we might want to know all of the tasks which are failing. We can achieve this behaviour using --continue option.
- Publishing Multiple Artifacts
We often require to publish build reports to some remote repository after build finishes. Gradle can create and publish multiple artifacts like apk(android), JAR, TAR, ZIP, etc.
- Customisable Logging
Printing the logs is very important to understand what is happening during the build execution, and it also helps in debugging and finding the issues. Gradle supports different levels of log like debug( -d), information (-i), warning(-w), stacktrace (-s) or no logs at all (quiet (-q)) etc. For example, we can use -s or --stacktrace to print out the stacktrace for all exceptions.
I am Sunil kumar, Please do follow me here and support #devOps #trainwithshubham #github #devopscommunity #devops #cloud #devoparticles #trainwithshubham
Connect with me over linkedin : linkedin.com/in/sunilkumar2807