Mailing-List: contact ant-user-help@jakarta.apache.org; run by ezmlm
Sender: kiniry@kindsoftware.com
To: ant-user@jakarta.apache.org
CC: kiniry@acm.org
Subject: Experiences with Ant.
Microsoft: Making the world a better place... for Microsoft.
From: kiniry@kindsoftware.com (Joseph R. Kiniry)
Date: 18 Oct 2000 11:31:37 -0700
Message-ID: <trx3dhuuhkm.fsf@adsl-63-198-73-142.dsl.lsan03.pacbell.net>
Lines: 109
User-Agent: Gnus/5.0807 (Gnus v5.8.7) XEmacs/21.1 (Bryce Canyon)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii

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                    http://www.cs.caltech.edu/~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...)