Over a million developers have joined DZone.
{{announcement.body}}
{{announcement.title}}

Building can be Smooth

DZone's Guide to

Building can be Smooth

· Java Zone ·
Free Resource

Automist automates your software deliver experience. It's how modern teams deliver modern software.

Since I wrote my first build script (it was Ant's build.xml) I wondered why build systems are so broken. They are not only hard to read (as some general purpose languages) they are also hard to write. Either you have to fight with mind blowing syntax and create/specify temporary directories for each task you perform (see Ant) or dig through documentation to find what is required file hierarchy and how to change default behavior of the system (see Maven). I wanted something that has the simplest language possible and yet does not have hidden things under the hood. Sounds impossible?

I wrote this article because I want to convince you that build system can be simple. Consider a build script that performs following task: "Takes all files from 'src' directory, compiles them with javac compiler, packages result class files into myapp.jar file". If you try to automate that using Ant or Maven you notice a strange thing. Your build script will be much longer than the description of the task in English prose above. This is terrible. Languages (especially computer programming languages) were invented to convey thoughts / ideas in simplest possible form. We want to pass data keeping information to words ratio at the highest level. None of the build tools I knew could do it.

However, the solution to the problem is quite simple. We can describe our process in a readable and simple way. All we need is a proper language for that task. For sure It's not the one embedded inside XML tags or one with complicated DSL packed inside Groovy language. It's the one created specifically for building software. Let's see how our ideal build language could look like. For the task mentioned above (compiling java files and packaging them into a jar file) I suggest something like that:

<code>

myapp.jar : files("src") | javac | jar ;

</code>

That simple code snippet conveys all the information necessary for a build system to perform the mentioned task. It is much shorter than English prose and, what's most important, it should be self explanatory for any software engineer. You don't have to fight with XML syntax here. You don't have to specify where to store *.class files - you don't care anyway - build system will take care of creating temp directories. You don't even have to specify where myapp.jar should be put - build tool will create some output directory for build artifacts and informs you where it has stored results upon success.

I discussed this idea for a long time with many people and I haven't seen much enthusiasm. "Building is hard that's why build tools sucks" they say. I decided there's only one way to convince the unconverted, so I built the thing. It's still a pretty early version (0.6.0) but it's good enough so I can use it in my java projects. There are even more features I didn't mention here and you would probably love, like content based caching of results so no calculation is ever run twice on your machine. If you want to join the revolution, just follow the link to http://www.smooth-build.org/ to find out more.

Get the open source Atomist Software Delivery Machine and start automating your delivery right there on your own laptop, today!

Topics:

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}