ant-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Adam Murdoch" <>
Subject RE: Experiences with Ant.
Date Thu, 19 Oct 2000 03:00:09 GMT


Something that may not be immediately apparent from the docs is how
incredibly easy it is to extend ant.  Writing and installing a new task is
very simple and very painless.  A home-spun task can leverage all the
cross-platform features that ant provides, in addition to being able to use
any of the built-in tasks, and features like file matching.  These sorts of
things _can_ be done in a make environment, but the solutions are (in
general) nowhere near as integrated or straight-forward.

Or as portable.  And portability was definitely the thing that won me over
to ant.  As a cross-platform build-tool, ant wins hands-down against
anything else out there.


> -----Original Message-----
> From: []
> Sent: Thursday, 19 October 2000 4:32 AM
> To:
> Cc:
> Subject: Experiences with Ant.
> Hello Ant Users,
> A fellow developer is advocating switching from GNU make to Ant
> for a large,
> multiplatform Java development effort.
> I've read the Ant documentation and am experimenting with the
> tool, but I've
> seen too many build tools come and go over the years (whereas
> make is still
> around and used by 1,000s of projects) to get too excited about Ant.
> Attached is my review of Ant vs. Make.  Is there anything I'm
> saying that is
> off-base?
> Can anyone say anything, pro or con about making such a switch?
> Finally, why aren't any of the Jakarta lists web archived?  This
> fact makes it
> very difficult to judge the size, quality, and disposition of the user and
> developer communities.
> Best,
> Joe Kiniry
> --
> Joseph R. Kiniry          
> California Institute of Technology        ID 78860581      ICQ 4344804
> ---
> I've been reading and evaluating Ant 1.1 for the last hour or so.
>  Here's what
> I've found.
> Pros:
> 1. Specification of PATH and CLASSPATH elements are operating system
> independent; Ant transforms ';'s to ':'s and vice-versa as appropriate.
> 2. File pattern-matching for building lists, including matching arbitrary
> directory trees with the "**" construct (nice).
> 3. Large set of built-ins tasks including java, javac, javadoc,
> rmic, cvs, and
> many of the standard command-line tools like chmod, rename,
> patch, touch, etc.
> 4. Supports "classic" (JDK 1.1/1.2), "modern" (JDK 1.3), and
> jikes compilers.
> 5. Supports what are called "build events" which means that you
> can couple Ant
> with arbitrary Java code that uses a listener-based mechanism to receive
> signals from Ant for a set of built in events (e.g. build finishes, task
> started, etc.).  No examples are included though.
> 6. Learning Ant isn't too bad - perhaps an hour of reading then
> regular use
> will be all that is necessary.
> 7. Ant development is pretty active.  It looks like there are two or three
> main developers working semi-regularly on it.  There hasn't been a second
> stable release yet (1.1 was first public release), so it is unclear how to
> take advantage of new work in the build tree (junit, jlink,
> javacc, sql, ejb,
> Perforce tasks).  I've grabbed the latest checkout of the build
> tree to see
> how stable it is.
> Cons:
> 0. Very weak reasoning for the first element in their
> documentation ("Why?").
> Summarized: The author of make didn't like any of the half dozen
> build tools
> out there for unspecified reasons and had misplace concerns about
> "extending"
> these tools in OS-specific ways (i.e. claims that the only way to
> do something
> "new" with make is to write a new command-line tool in C).  Also,
> of course,
> the infamous, "Makefiles are inherently evil as well.".  Why?  Because
> sometimes you put a tab in the wrong place.  That's all.
> 1. The Jakarta projects at Apache use Ant, they are the ones that actually
> developed it.  I've found a few other projects that use Ant by
> searching for
> "build.xml" in Google.  Searches on several other terms yielded
> no new hits.
> The projects using Ant include TView, one of the free EJB servers
> (ejboss),
> Infozone (another XML server-side framework), and Ozone (an OS
> Java ODBMS).  I
> get no hits on Ant-using projects at SourceForge, though I'm sure
> there must
> be a few.
> 2. To run Ant one has to set ANT_HOME and JAVA_HOME environmental
> variables
> and run a bourne shell script.  No such script is provided for
> Windows, so you
> either write your own batch file or run Ant "natively".
> 3. When you are executing platform specific applications (like
> the exec task,
> or the cvs task), the property ant.home must be set to the directory
> containing a bin directory, which contains the antRun shell
> script necessary
> to run execs on Unix.  No such script exists for Windows.  It is
> unclear how
> this works on Windows.
> 4. A few of the built-in tasks only work under UNIX, but they are
> reasonable
> ones.
> 5. The Ant Users list is fairly quiet.  I subscribed a couple of
> days ago and
> no messages have been sent.
> Pro and Con all in one:
> 1. Has some nice token-filtering stuff (kinda like a global
> search-and-replace
> a la #include)
> 2. Ant uses XML as a structured data format, therefore it is
> parsable by other
> tools.  On the other hand, Ant's build files is much more sensitive to
> syntactic errors than makefiles (i.e. closing tags, proper
> quotation, use of
> properties and tags, etc. vs. proper tabbing).  In fact, when parsing an
> incorrect XML file Ant typically doesn't even tell you what is
> wrong, it just
> throw the exception from the parser.
> 3. Tasks to fix CR/LF conversions to native/local system, convert tabs to
> spaces, adjust tab lengths, eofs.  Since these are fairly
> powerful operations
> one can easily mess up a whole build tree, but that is pretty typical with
> handing someone a large gun - they need to know where to point.
> (I like this
> feature, but in the wrong hands...)

Do You Yahoo!?
Get your free address at

View raw message