Saturday, December 3, 2011

What Is It With "ant"?

I believe build engineering is by far the most important technical discipline in release management. With a good build system, you can do anything; without one, you are constantly hobbled. Over the past, I've had plenty of opportunities to examine and develop build systems.

Twenty years ago, things were a lot simpler: there was make, and not much else. Being first of a breed, it had a lot of cosmetic and functional flaws. It also was unusual in that it was a non-deterministic rules based system. Many developers failed to appreciate the power of that concept, and instead attempted to apply their procedural knowledge to make and failed. Very few people understood and liked makefiles.

Then came the explosion of UNIX variants, and then came Microsoft DOS and Visual Studio, and they did everything to be different. Software had to be built for dozens of different platforms, all with their own dialect of make and differing shell syntax...

When Java started becoming mainstream, there was an obvious need for a build system to support java build processes. Make would be quite adequate to support it, but which version and flavor of make? Or more importantly, which version of the command line interpreter (shell) is to be used to get make to work?

Now it is true that by the time Java became popular, most of the UNIX make variants have been merged into GNU make, nowadays the de facto standard for make on UNIX. Unfortunately, most java developers worked on Microsoft Windows, with their rather horrid Batch File langage. Nobody can really blame the java developers as they avoided using it.

Instead, they developed ant: a rule based specification based on XML, with Java itself being the underlying shell language, exporting a variety of basic functionality in a platform independent way:
  • Compiling .java files
  • Aggregating them into .jar files
  • Copying files
  • Creating directories
  • Performing version control operation
The idea is that any operation not yet supported by ant could be implemented in Java, and then invoked via the XML based specification file.

Even though it is sad to see that ant in large part retraced the development history of make, with the same stumbling stones (e.g Recursive Make Considered Harmful) and a serious lack of features (e.g. Pattern Rules), it is an understandable tradeoff between platform independence and feature set.

So I guess I'll just have to live with it.

Thank God there's Maven.

4 comments:

  1. In 2004, I tried to use Ant instead of Make on a C++ environment. It was a nightmare. It understood Java and nothing else.

    Maven is in that state now. If you're doing a Java environment, especially if you're willing to do it the way it wants you to, it's The Best Tool Evar. If you're doing anything else, it's horrible.

    I just tried to use Maven in a mixed environment (C#/Unity/Java/Flash) and it's just not worth the pain. Ant is working out for us, though, now. It's matured.

    ReplyDelete
  2. I totally feel the pain. I will most certainly post some more about build system, and how in my opinion, we've actually regressed into a lowest common denominator situation.

    People in the past developed excellent build systems (jam, cook), but they all had the flaw that they only worked on some UNIX variant, whereas Visual Studio took over the developer universe. Only CMake and ant address the portability issue, and both are a painful throwback for anyone used to the power tools of times gone by.

    Definitely material for further postings.

    ReplyDelete