ant-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Christopher Elkins" <celk...@scardini.com>
Subject Re: Experiences with Ant.
Date Wed, 18 Oct 2000 18:52:57 GMT
> 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?
>
See comments inline.

> 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.
>
http://archive.covalent.net/

> Best,
> Joe Kiniry
> --
> Joseph R. Kiniry                    http://www.cs.caltech.edu/~kiniry/
> California Institute of Technology        ID 78860581      ICQ 4344804
>

--
Christopher Elkins


> ---
>
> I've been reading and evaluating Ant 1.1 for the last hour or so.  Here's what
> I've found.
>
> Pros:
>
<snip>
All good points. ;-)

>
> 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.
>
One of the primary advanatages of Java obviously is its cross-platform nature.
Make "sorta" works on most platforms, but it's yet another thing to
compile/install. Why not isolate your platform-specific tools to just the JDK?
Obviously, if you're using Ant on one platform only, this argument has little
merit.

FWIW, I started my projects with make. However, as soon as Ant appeared I
dropped make immediately (for Java projects, that is). I don't have eons of
experience with Makefiles, but I do know that dealing with misplaced tabs was a
major PITA. I much prefer the syntax of Ant's XML-based build files.

> 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.
>
AFAIK, every Java-based Apache project uses Ant now. These include the projects
hosted at jakarta.apache.org as well as those at java.apache.org and
xml.apache.org. That sounds like good momentum to me, especially if you believe
that the ASF isn't going away anytime soon.

Other OSS Java projects may not use Ant due to licensing considerations. (IANAL,
so take that with the requisite grain of salt.)

> 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".
>
No, batch files do exist for Windows.
(http://jakarta.apache.org/cvsweb/index.cgi/jakarta-ant/src/bin/) Were they not
included in the distro you downloaded?

> 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.
>
See the above response.

> 4. A few of the built-in tasks only work under UNIX, but they are reasonable
> ones.
>
True, chmod obviously would have no utility on Windows. Why do you consider this
a con?

> 5. The Ant Users list is fairly quiet.  I subscribed a couple of days ago and
> no messages have been sent.
>
Like all lists, traffic ebbs and flows. The dev list is quite active, though.

> 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.
>
I'd disagree with you on whether XML is more sensitive to syntactic errors than
Makefiles. But that's just personal preference. ;-)   If you're at all familiar
with XML, working with the build files is cake.

> 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...)
>
That's why you'd only want to use these tasks when creating distributions.
However, I don't see this as being any different than executing 'rm -rf' inside
a Makefile.



Mime
View raw message