Java Magazine, Jan/Feb 2017
ORACLE COM JAVAMAGAZINE JANUARY FEBRUARY 2017 24 tools a programming language should you ever need them if else classes inheritance composition and so on is a clear step in the right direction Dependencies The 1 job of a build tool is to execute a sequence of tasks in a certain order and to take various actions if any of these tasks fail It should come as no surprise that all the build tools I have come across on the JVM or outside allow you to define tasks and dependencies between these tasks However a lot of tools dont adequately address project dependencies how do you specify that project C can be built only once projects A and B have been built With Gradle you need to manipulate multiple build gradle files that in turn refer to multiple settings gradle files In this design dependent modules need to be defined across multiple files with diferent roles build gradle and settings gradle which can make keeping track of these dependencies challenging When I started working on Kobalt I decided to take a more intuitive approach by making it possible to define multiple projects in one build file thereby making the dependency tree much more obvious Here is what this looks like val lib1 project name lib1 version 01 val lib2 project name lib2 version 01 val mainProject project lib1 lib2 name mainProject version 01 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 All the projects are then sorted topologically which means the build order can be either lib1 lib2 mainProject or lib2 lib1 mainProject both of which are valid Also note that the previous example is a valid and complete build file and the repetition can be abbreviated further but Im keeping things simple for now Being able to keep the project dependencies in one centralized place makes it much easier to understand and modify a build even for a complex project Using multiple build files in the subprojects own directories should still be an option though Make Simple Builds Easy and Complex Builds Possible A direct consequence of the functionality described in the previous section is that the build tool should let you create build files that are as bare bones as possible Convention over configuration Most projects usually contain just one module and are pretty simple in nature so the build tool should make such build files short and it should implement as many sensible defaults as possible Some of these defaults include those shown in Table 1 With such defaults the simplest build file for a project should literally be less than five lines long And of course the build tool could perform further analysis to do some addi No matter how extensive the build tool is it will never be able to address all the potential scenarios that developers encounter every day so it also needs to be expandable
You must have JavaScript enabled to view digital editions.
