ant-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jesse Tilly <JTi...@hoteltools.com>
Subject RE: Experiences with Ant.
Date Wed, 18 Oct 2000 18:58:10 GMT
Having made this decision myself, I'm very curious about other people's
opinions.  I have made a large project makefile set and am in the process of
making a large project antfile set.  I am using Ant for the following
reasons:

(1) The use of XML instead of formatted text files is much more portable.
Without being fascist about development workstations, I cannot assume how
people use and run make.  They may run it in Korn shell, or Bash.  They may
have aliases set up that do different things.  In windows, I had to be sure
that no one ran Cygwin as its handling of /, ; was different and the ways
javac 1.1, javac 1.2 and jikes handled the paths, etc made for headaches.
The only properties my users have to set to use Ant are the JDK location,
WebLogic's location, and the source location.  The XML and Ant handle it
from there.

(2) For Windows, nmake (from Microsoft) works much better, but it's
makefiles are not compatible with GNU Make.

(3) The increased flexibility of elements makes it easier for me to generate
build information dynamically.  I could write a Java program that could
produce the dynamic portions of an antfile and *know* it'll work for my
developers (on Win2k) and for the build group (on Solaris).

(4) That tab/CRLF issue is way bigger than I'd like it to be.  Too many
editors and text processing programs are "smart" and try to modify the
makefiles.  Replacing tabs with spaces or adding CRLF.  Unless stored as
binary, VSS adds CRLF to my makefiles.  Ugly situation when pulling them out
for Solaris.  We've eliminated VSS for this reason, but it was a reason for
using Ant.

Ant is not a replacement for Make.  If I was writing Gimp, gcc, make itself,
or any other OS-specific tool, make (plus autoconf) is still the way to go.
however, the non-definitive dependent nature of Java program compilation,
the high likelihood of a heterogeneous development environment, and the ease
of writing XML for web junkies makes Ant a perfect choice for Java projects.
I believe that Ant will eventually add elements for gcc, yacc, bison, even
python.  Heck, I could use jPython to make a quick-dirty build/test manager
that parses XML into a tree, allows me to edit it on the fly, can run any of
the targets and embed things like JUnit or even the weblogic console.
That's the beauty of this tool.  I still have hair pulling moments as I
discover another bug in Ant and have project managers ask me why we're using
it, but they don't know that it took me 1 month to create a build
environment using make that could be universally used by all developers,
updated by anyone without breaking and deploy/install/remove all parts of a
WebLogic project.  It took me one week for Ant.  Granted, I knew what to
avoid environment-wise from the make experience, but I will firmly stand
that, having done both *for Java projects*, Ant is better.

Jesse

-----Original Message-----
From: kiniry@kindsoftware.com [mailto:kiniry@kindsoftware.com]
Sent: Wednesday, October 18, 2000 2:32 PM
To: ant-user@jakarta.apache.org
Cc: kiniry@acm.org
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                    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...)

Mime
View raw message