Getting to know Gradle — Comparative
If you have ever dealed with compilation systems, frustration can be one of the feelings that come and dominates you in a large part of the time when you think about the challenges that you faced. Shouldn´t the construction tool naturally helps you with the objective to automize your project? Instead of this, you had to compromise the maintenance capacity, facility of use, flexibility, extensibility, or performance to do this automation.
Let´s imagine you want to copy a file to a specific place when you are building a launching version of your project. To identify this version, you verify the information in the metadata, describing your project. If it corresponds to a specific numbering scheme (1.0-RELEASE, for example), you copy the file from point A to point B. Starting from an outside perspective, this may sound as a trivial task. If you must trust in XML, the construction language of many traditional tools, expressing this simple logic is quite difficult to implement and read in the file. The answer of the construction tool is to add a script functionality through mechanisms of extensions out of the standard. You end up mixing script code with XML or invoke external scripts to your construction logic. It is easy to imagine that you will need to add more and more personalized code thought time. As a result, you inevitably will introduce accidental complexity and the maintenance becomes harder, since it is not standardized in all the companies. Wouldn´t it make more sense to use an expressive language to define your construction logic in the first place?
Here is another example: Maven follows the paradigm of convention-over-configuration through the introduction of a standardized project layout and the construction of a life cycle for Java projects. This is a great approach, if you want to guarantee a unified structure of application for an initial project — a project which still doesn´t have any restrictions imposed by a previous job. However, you might be the luck person that needs to work in one of the many legacy projects that use different conventions. One of the most rigorous conventions of Maven is that a project needs to produce an artifact, such as a JAR, WAR, or EAR file. But how do you create the files in JAR with different source codes without having to change the structure of the project? Only for this effect, you would have to create two separate projects. Once again, even if you can make this happen with an alternative solution, you will continue with the sensation that your construction process will have to adapt to the tool, not the tool to your construction process.
These are only a few of the restrictions that you may have found with the existing solutions. Many times, you will have to sacrifice non-functional requisites to model the automation domain of your company. But enough with the negativity — let´s see how Gradle fits into the landscape as a construction tool.
The evolution of Build tools for Java
Let´s see how the construction tools have evolved during the years. Two tools have dominated Java construction projects: ANT and Maven. Throughout the years, both tools have improved significantly and extended their resource set. Even though they are both highly popular and became standards in the industry, they have a weak point: the construction of the logic must be in XML. XML is good to describe hierarchical data but does not attend in expressing the flow of the program and conditional logic. As a construction script grows in complexity, maintaining the code for construction becomes a nightmare.
The first version of ANT was launched in 2000. Each working element [a target, in ANT vocabulary] may be combined and reutilized. Multiple targets can be chained to combine individual working units in complete workflows. For example, you can have a target to compile the Java source code and another for the creation of a JAR file that packages the class files. Building a JAR file only makes sense if you compile for the first time the source code. In ANT, you make the target JAR depend on the destination of compilation. The ANT does not give any orientation as to how to structure your project. Although it allows maximum flexibility, ANT makes each construction script unique and difficult to understand. The external libraries for your project are normally sent to the version control, because there is no automatic mechanism to pull them from a central location. The first versions of ANT demanded a lot of discipline to avoid repetitive code. Its extension mechanism was weak. As a result, the practice of bad coding of copying and pasting code was the only available option. In order to unify the project layouts, the companies were obliged to create and impose internal standards.
The 1.0 version of Maven, launched on July 2004, tried to relief this process. It supplied a standardized project and directory structure, as well as dependency management. Unfortunately, the personalized logic is difficult to implement. If you want to leave Maven conventions, writing a plugin, called Mojo, is generally the only solution. The name Mojo could imply in a simple, easy, and sexy manner to extend Maven; in reality, writing a plugin in Maven is excessively complex and laborious.
Later, ANT reached Maven, through the introduction of dependency management through the library Apache Ivy, which can be totally integrated with ANT to specify declared dependencies needed for the compilation process and packaging of its project. The dependency manager of Maven, as well as Ivy, supports solving the transitive dependencies. When I talk about transitive dependencies, I mean the library graph demanded by their specific dependencies. A typical example of transitive dependency would be the library Xerces of XML analyzer that needs the APIs XML libraries to work correctly. Maven 2, launched on October 2005, had a convention idea regarding a further configuration. Projects which consist of many modules could define its dependencies within itself.
In the present days there is a large quantity of people searching for alternatives for compilation tools. We see a change in the use of XML to a more expressive and readable language to define construction. The construction tool that transports the idea is GANT, a DSL above ANT and written in Groovy. Using GANT, the users now may also combine characteristics of Groovy with their existing ANT knowledge without having to write XML. Even though it is not part of the Maven core project, a similar approach was proposed by project Maven Polyglot, which allows you to write tour compilation of logic definition, which is the object file for the model project (POM), in Groovy, Ruby, Scala or Clojure.
We are in the imminence of a new era of application development: programming and polyglot persistency. Many applications of today incorporate various programming languages, each one more adequate to implement a domain of a specific project. It is not uncommon to face projects which use languages from the client side such as JavaScript that communicate with a mixed, multilingual back-end, such as Java, Groovy, and Scala, which in turn makes calls to an application inherited by C++. It is all about the correct working tool for the job. Although there are the benefits of the combination of several programming languages, its Built tools needs fluent support and infrastructure. JavaScript needs to be incorporated, mined, and compacted, and its server and legacy code side need to be compiled, packaged, and implemented.
Gradle fits in perfectly with what the compilation tools generation demands and satisfies many requisites of modern construction tools (Figure 1). It provides an expressive DSL, a powerful convention over the configuration and dependency management approach., It makes the right movement to abandon XML and introduce the dynamic Groovy language to define your logic of construction. Sounds convincing, no?
