What’s after Ant?
At a copasetic CITCON session in Dallas recently, Martin Fowler mused on the “future of build languages” and suggested that due to Ant’s inability to be richly expressive (think conditionals, looping, etc) that future build platforms will be modeled as native domain specific languages much like Rake is in the Ruby world (or SCons is in the Python world). Note, Ant is a DSL, but it is expressed in XML not Java, man.
Because it’s my bag, I largely agree with Martin, however, given Ant’s deep penetration within the Java market, compared to Maven (which, I think is one step closer to a Rake-like build platform for Java) I wonder if the Rake model can come to fruition and obtain any reasonable mindshare. Sure, there are hip projects underway like Raven (which combined forces with JRake recently), which does a number of useful things such as compilation, testing, etc, but ultimately, as Ant is the de facto build platform for Java, practically every tool out there bundles an Ant task. If you want to use Raven and would like to generate a report with JavaNCSS, for example, you might have to write some custom Ruby code to fire the JavaNCSS process off. Hopefully, the increased velocity of development on JRuby will alleviate this issue as it appears JRake makes use of Ant tasks.
It seems to me that if a more DSL-like platform is going to gain any mindshare within the Java community, it’ll have to take advantage of the rich infrastructure present within Ant (Maven did this though and hasn’t overtaken Ant by any means). One such project is Groovy’s Gant, which enables you to specify builds via Groovy rather than XML. Groovy provides expressiveness and is native to the JVM; however, given the history of Java build platforms, I suppose Gant’s adoption will lag behind Maven by a long shot, man.
Interestingly, a few individuals suggested that some of the issues associated with Ant were not necessarily related to Ant, but to people’s usage of the tool. This made me remember an excellent article published a number of years ago that largely still holds true: “Top 15 Ant Best Practices.”
Ultimately, Ant is the de facto standard for building Java applications. Like it or not, it works for 90% of those that attempt to employ it. There will be innovative and clearly more flexible build platforms that’ll pop onto the scene, but displacing Ant is much like thinking that Macs or Linux will overtake Windows installations (in the near future). Displacing these kinds of market leaders takes seismic paradigm shifts (like we are currently seeing with Disco music).
What’s after Ant? Well, we’ve seen what’s next: it’s Rake (or Raven or Gant), but for Java, the vast majority of the community doesn’t appear to care. That’s so establishment.
| Related odds and ends | ||
|---|---|---|
9 comments Saturday 28 Apr 2007 | Build Process, Groovy, Ruby
9 Responses to “What’s after Ant?”
I think that the next build tool for Java needs to use Java, the language. Perhaps that will only seem practical after Java 7, when closures (and type inference?) add some of the necessary expressiveness.
Imagine persuading a Ruby developer to write their build in Smalltalk or Lisp. Similarly, there’ll be resistance when suggesting that a Java developer should write their build in Groovy or Ruby. Perhaps some would do it as an experiment to see what those languages are like, but other than that, ant works, so ant’s what will be used until something better turns up, and ‘better’ includes the learning curve.
The answer to this question pre-supposes that in the future we will still need “build languages”. There are a number of tools and IDEs out there that now “auto-generate” much of the build process – certainly the basic machinations of compilating/testing/packaging. Eclipse for example (and tools built on top of it) can be run in “headless” mode which requires very basic Ant build scripts that essentially call workspace functions, i.e. build my workspace.
If you look at the composite build process as a whole there are obviously other functions around the language specific process, for example creating a new workspace out of source control, baselining, labeling, deploying etc. I still believe people will want to “script” up this composite process, however most of these are not implementation specific and could be executed in any scripting language. So maybe we should just see Ant as a generated code, necessary for the build process but look for the best, richer, non DSL – there are candidates out there it just needs people brave enough to adopt them.
Some random thoughts, man….
1. Things that we use _all the time_ tend to resist change. For example, in natural language, the verbs “to be” and “to have” are notoriously weird because they aren’t made “regular”, as is the tendency with less-used verbs.
Similarly, build tools have amazing resilience. The industry suffered with ‘make’ for decades. The fact that Ant saved us from ‘make’ is enough for it to go into the Hall of Fame.
2. Maven has some really neat ideas but IMHO the execution was shoddy. V 1.x proved the folly of XML as a scripting language (was Jelly the tool?), but also that poor documentation outweighs a Grand Scheme (the POM).
3. I have not used Rake. I am intrigued by Gant because it builds on top of Ant and gets around some of the awkwardness of XML as a scripting syntax. My hope is that Gant learns from Maven and nails the documentation aspect. (Maybe it has — I don’t know)
4. I think the big question is, man: is anyone using anything other than Ant or Maven? Anyone using Gant/Rake/etc?
Savant.
I feel that the main build issues are these:
1. Standard naming
2. Versioning
3. Historical builds
4. ClassLoading
5. Simple plugins
6. Real language support (i.e. Ruby or Java or Groovy)
7. Flexibility
Savant solves all of these except #5, but I’m working on that
You can define plugins in any language. Plugins are versioned fully and plugin dependencies are managed. Savant handles class loaders so that two plugins can use the same JAR of different versions. It provides standard naming conventions since it uses plugins. And unlike Maven it is much more flexible. You can override, extend and change plugins. You can produce multiple JAR files and pretty much do whatever you can dream up. You can target specific compilers rather than the JDK running the build. You can unit test effectively. It has a ton of other great features as well.
Now, Savant 2.0 has been in development for a long time and really needs some help. Anyone interested in a building out a great tool for building software, left me know. I’m hoping to have a beta and a final release of 2.0 sometime this year. The more folks that want to help out the faster it will come along.
Hello. We have a non-profit resource that we want to share with you guys. The following page shows examples of Ant Scripts:
Ant Script Samples
On the site, you will find other information pertaining to building large-scale java applications, as well as other helpful hard-to-find common configurations.
[...] Gant is a build system that sits on top of Ant, which uses Groovy as the platform language, rather than XML; thus, build files are much more flexible when it comes to logic (such as conditionals and more importantly, custom behavior). [...]
[...] Or via Ant, like so: [...]
??????: ?? Raven ?? Java ??…
Ant ????? Java™ ????????????????????????? XML ??????????????????????? ?????? ????????????? Ruby ??…
[...] in the Java space, Ant is the de-facto build platform; consequently, the future of build languages will most likely need to leverage the extensive infrastructure in place to support Ant– [...]