Java Reference
In-Depth Information
Ant builds are based on XML
,
and XML is not a scripting language.
Builds inevitably need
to be customized and usually vary depending on whether the project is in development,
test, or production mode. Ant allows you to set properties, but properties aren't variables.
It's especially difficult to do complex branching logic in an XML file.
Ant says nothing about dependency management
. It assumes you have all the required lib-
raries available and that you can build a file set to hold them and use that as your classpath.
The Ivy project (also from Apache) fills that gap, and the combination of Ant and Ivy is
much more common now than Ant alone.
XML was designed to be processed by programs, not people
. Reading a short XML file
isn't hard. Reading a long, involved one is, and even the trivial build file presented in this
section is over 50 lines long when a few basic tasks are included.
The built-in Ant tasks are very low level
. As a result, Ant build files quickly grow long and
complex and involve a lot of repetition.
For all these reasons and others Ant was ripe for a higher-level replacement. That role was
filled by the Maven project, which is either a blessing or a curse depending on your exper-
iences with it.
5.4. The Java approach, part 2: Maven
I'm going to confess up front that Maven is hard to talk about rationally. Its best features
(establishing a conventional project layout, managing dependencies, providing a rich plu-
gin architecture) are also considered some of its worst features (difficult to work outside its
conventions, hard to manage transitive dependencies, the whole “download the internet”
problem). I can honestly say I've never encountered a technology that's both common in
Maven in a group of developers, and someone will refuse to discuss “the M word.” Yet, at
the same time, somebody else will quietly say that they can make it do anything and don't
understand what all the fuss is about.
6
Except possibly for every Microsoft technology ever.
