Java Magazine, Jan/Feb 2017

ORACLE COM JAVAMAGAZINE JANUARY FEBRUARY 2017 23 tools files which was quite innovative at the time Ant also came up with the concept of tasks that can be defined either in the XML file or as external tasks implemented in Java that the tool looks up Even though Ant is still used in legacy software it is largely considered deprecated today and looked at as the assembly language of build tools very flexible offering a decent plugin architecture but a tool that requires a lot of boilerplate for even the simplest build projects Now lets dive more specifically into what you should expect from your build tool Syntax Lets start with the most visible aspect of a build tool the syntax of its build file Obviously I want my build tool to have a clean and intuitive syntax but youll be hard pressed to find a general consensus on what a clean syntax is so I wont even try to define it I would also argue that sometimes syntax is not as important as the ease with which you can write and edit your build file For example Mavens pom xml file has a verbose syntax but Ive found that editing it is pretty easy when I use an editor thats aware of this files schema Gradles popularity came in good part from the fact that the syntax of its build file was Groovy which is much more concise than XML My personal experience has been that Gradles build files are easy to read but hard to write and Ill come back to this point below but overall there is a general agreement that the Gradle syntax is a step in the right direction What is more controversial is the question of whether a build file should be using a purely declarative syntax for example XML or JSON or be a valid program in some programming language My experience has led me to conclude that I want the syntax to look declarative because its sufficient for most of my build files but that I also want the power of a full programming language should I need it And I dont want to be obliged to escape to some other language when I have such a requirement the build file needs to use the same syntax This observation came from my realization that I have often wanted to have access to the full power of object oriented programming in my build files so that I can create base class tasks that I can specialize with a few variations here and there For example if my project creates several libraries I want to compile all these The project directive which is an actual Kotlin function can take dependent projects as parameters and Kobalt will build its dependency tree based on that information libraries with the same flags but the libraries need to have a different name and version This kind of problem is trivially solved in object oriented languages with inheritance and method overriding so having this kind of flexibility in a build file is desirable On a more general level complex projects are often made of modules that share a varying degree of common settings and behaviors The more your build system avoids requiring you to repeat these settings in multiple locations or diferent files the easier it will be to maintain and evolve your build All build tools ofer in varying degrees to help you set up your modules their dependencies and their shared parameters But I cant say I have found one that makes this inherit and specialize aspect very intuitive not even my own build tool Maybe the solution is for modules to be represented by actual classes in the programming language of your build files so you can use the familiar inherit and override pattern to capture this reuse In the meantime I think the approach of using a DSL that is a valid program and that ofers you all the facilities of