ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Steve Loughran" <>
Subject Re: Ant on slashdot
Date Sun, 17 Nov 2002 17:50:33 GMT

----- Original Message -----
From: "Steve Cohen" <>
To: "Ant Developers List" <>
Sent: Sunday, November 17, 2002 06:43
Subject: RE: Ant on slashdot

>I too want to chime in with my words of praise.

I like a happy audience.

>There are always things you missed.
>Like when was
><property name="foo" location="bar"/>
>instead of
><property name="foo" value="/where/the/hell/is/bar"/>

>Go ahead, tell me version 0.9, I don't care, but until I bought the book
that had always managed to elude >me.

Its been around for ages and ages, but most people are ignorant of why and
when to use <property location>. It only really matters when you start
making builds from sub projects. By which time, if you used the wrong
declaration, you have a lot of reworking to do. We used <property location>
from the outset to set a good example and reinforce good habits, like doing
testing wherever we could.

>Also the parts about using the <ant> task to launch subsidiary scripts
provided me with many useful >ideas.  This would be a subject for another
whole book, "Advanced Ant", dealing with subjects like

>when to use <antcall> to call a task within the file
>when to use !ENTITY inclusion
>when to <ant> to make a call into another build file (such as a library)

Entity inclusion lets you share declarations across build files (properties,
taskdefs, targets). Library calls reduce replication across build files and

I'd like to think we covered a lot of the advanced ant, you'd have to be
doing some very leading edge stuff to go beyond the book.  Maybe EJB and
XDoclet merit more detail, as would continuous integration; Gump and
CruiseControl are complex beasts. Then there is maven and things I should
know about and dont. These are all kind of post-ant build and dev process
topics, leading edge of the Apache/Sourceforge java development toolchain.

Which is an interesting phrase isnt it, "the Apache/Sourceforge java
development toolchain". Seems to me that after d/l-ing a JDK version, and
jikes, the rest of my product line comes from two places:

Apache: ant, tomcat, struts, xerces, xalan, axis, XML-fop (docs), gump,
cactus, log4j, maven, velocity
Sforge: jedit, junit, httpunit, hsqldb, xdoclet, checkstyle, ant-contrib,

That just leaves out Castor, from exolab, and Intellij IDEA.

The point I think I'm trying to make is that the java community has
effectively evolved the core toolchain for java dev, both open source and
closed source. And when you compare Java to .NET, it is the community and
resulting codebase that give Java the (current) edge.


To unsubscribe, e-mail:   <>
For additional commands, e-mail: <>

View raw message