Hey guys, Have you seen black art, well, here’s the truth – Besides black art, there is only automation and?mechanisation. It’s this era, there is a new name for magic, its called Automation . Each and everything is being automated to save extra efforts and time and that too without the cost of accuracy. Isn’t it cool? This article is going to be short and interesting one. If you know about Gradle then maybe it won’t be that much interesting to you but hey! Who doesn’t like magic??
What is Gradle?
If I have to explain Gradle in short and not in a fun way then I would say that – Gradle is a Build Automation Tool.
Now let’s slowly dig down the meaning of those words? Gradle is nothing but a very powerful tool to achieve Build Automation. It’s important that we understand Build Automation before getting into the ways to achieve it.
What is Build Automation?
Build automation is the process of automating the creation of a software build and the associated processes including: compiling computer source code into binary code, packaging binary code, and running automated tests.
If you want to know more in details about getting started with gradle then follow this article: org/current/userguide/userguide.html
Why we need Build Automation?
Maybe because of these reasons:
- People don’t know the process and that becomes a problem
In large organization there is a miscommunication between people and teams that could take up loads of time. With Build Automation, a single person can sit and outline all the required steps to deploy the project. Create a nice document side-by-side and finally create a template and test it on database. Once everything is working fine, publish that document to your team so that they will follow the exact same thing required to deploy the project. This way there will be a process to follow… - Time spent in fixing a fault is costly, so better avoid it
I understand that fault is a part of a Software Development phase and it’s hard to avoid. But what if the time required for fault management stretches more than the project development time. Then it is not fruitful at all. How good it would be if there is a set of document for everything that people can follow and ?avoid the common bugs and pitfalls.
- A single admin to administer the build, hence, more control
At times there are single admin with multiple developers working on the deployment process. The deployment experience should be same for all the developers. Therefore, a new documented outline will give admin more power over the entire deployment process.
- Manual is risky
I don’t think this point needs explanation :p
So, now that we know what is Build Automation and why we need it, we can better understand the ways of achieving it.
Gradle Build Tool
From a long time the only requirement of a Build tool has been to compile the source files and package them. But as business requirements has evolved overtime the responsibility of a build tool has also increased. A build tool has to work with multiple projects and multiple languages together and has to apply broad spectrum of testing. Gradle comes into the picture.
Gradle is a JVM based build tool and it makes use of the lessons learned from the earlier build automation tools such as Ant and Maven and did not force the developer to write configurations in XML files. Following a build-by-convention approach, Gradle allows for declarative modelling your problem domain using a powerful and expressive domain-specific language (DSL) implemented in Groovy instead of XML. Because Gradle is a JVM native, it allows you to write custom logic in the language you’re most comfortable with, be it Java or Groovy.
Why Use Gradle?
Gradle will definitely help you in making tedious tasks easier without compromising with the flexibility, usability, extendability and performance. In any large size project with multiple dependencies managing these become difficult and cumbersome. Gradle makes it real easy to manage dependencies between multiple projects. Java projects normally depends on large number of dependencies and to manage such dependencies require advance tools which provides easy management with less configuration.
Maven is one such tool, it is also used to manage dependencies. It follows the paradigm of convention over configuration by introducing standardised project template and build life-cycle for Java projects. This approach is quite good but only if you want have a single convention. Imagine if you have a project with multiple conventions, then it becomes a problem. Maven has one such convention that there must be one JAR in every project structure. What if you want to produce 2 different JARs from the same project with different project structure, then it becomes quite difficult to achieve that with Maven. Sure you will get workarounds but then these workarounds doesn’t come that naturally to you.
Gradle has learned its lessons from these build tools and it makes it really easy to work with it or I can say that Gradle comes naturally to you. Below mentioned description will convince you to adopt Gradle and why should you use it now –
How much less code does Gradle takes perform the exact same task done by Maven. On top of that it is more readable and uses the same language which you are used to.
Conclusion
If you are not using Gradle or haven’t used it before then I would recommend you to use it now. It is one of the best automation tool you will find out there. It’s very easy to use and more and more businesses are porting their projects to gradle. If you need help in convincing others about using it, then feel free to use the share buttons below. Please comment below for any discussion.
- How to become a Good Web Developer
- Simple Shopping Cart Application in Java using Collections
- Thinking in OOPs
And as always
Be My Aficionado 🙂