ant-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Donald <>
Subject Re: Experiences with Ant.
Date Wed, 18 Oct 2000 23:18:52 GMT
>1. Specification of PATH and CLASSPATH elements are operating system
>independent; Ant transforms ';'s to ':'s and vice-versa as appropriate.

to a degree. If the paths are all relative or all on same volume then it is
trivial - thou cross volume stuff (like going from C:/ to E:/) doesn't work
well cross platform (thou it makes no sense for it to ;])

>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.

currently there is two active committers 

>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
>"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.

thats not a con of ant thats a con of documentation ;)

thou the main advantages I see are
1. cross platform
2. much much simpler
3. programmatic control of tasks 

1 may or may not be important to you. Make not provide this in a consistent
way (I can think of at least 5 different versions of make that I have used
and have to take care for when maintaining x-Platfrom stuff.

2 is the main reason I like ant ;)

3 is convenient. Need a new task that reads a key from store, unlocks a
resource, performs an operation and then finishes ? In mae it could lead to
excessive scripting and hackery to get it to work while in ant you create a
task and set a few attributes. I guess this is an extention of 2 really ;)

>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
>get no hits on Ant-using projects at SourceForge, though I'm sure there must
>be a few.

A fair few of sourceforge projects use ant. 
How is this a con ?

>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
>either write your own batch file or run Ant "natively".

not sure about windows. But in *nix you not need to se ANT_HOME as it works
it out for it'self

>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.

again not sure about windows but you not need to specify it on linux as it
works it out for itself

>5. The Ant Users list is fairly quiet.  I subscribed a couple of days ago and
>no messages have been sent.

hmmm - wait for a deluge - it is one of the more busy lists but may go
quite for a while ;)

>Pro and Con all in one:
>1. Has some nice token-filtering stuff (kinda like a global
>a la #include)

needs to be more explicit IMHO so that you can control more precisely where
and when token filtering occurs

>2. Ant uses XML as a structured data format, therefore it is parsable by
>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...)

If you have a look at the way most apache projects work it (except for
velocity/turbine/* by Jon) most actually have 2 source trees. It is assumed
that that current source tree is always in native code but when you copy
the files to second tree you do all token/change crlf etc.

Most only use this functionality when building disttribution target and
have script files (.sh or .bat depending on platform).



| "Nearly all men can stand adversity, but if you want |
| to test a man's character, give him power."          |
|       -Abraham Lincoln                               |

View raw message