ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Lance Hankins" <lhank...@focus-technologies.com>
Subject Thanks for all the Ammo (RE: Need Ammo in Make vs. Ant argument)....
Date Tue, 12 Jun 2001 19:27:02 GMT
Thanks for all the Ammo in the Make vs. Ant Argument.  I'm posting below the
message I sent to management with respect to this issue.   I figure someone
else who's fighting the same battle may find this helpful (re-use at the
argument level).

I found the following two links especially helpful in legitimizing Ant and
comparing it to Make :

   http://www.sys-con.com/java/archives/0606/ford/index.html
   http://dcb.sun.com/practices/profiles/ant.jsp


Anyway - here's a cut-n-paste of the message I sent to our management :

----------------------------------------------------------------------------
--


I'd like to get together and talk about this at some point.   We are
not using a different version of Make.  We are using a build tool
called "Ant" which comes from the Apache Software Foundation.   A few
facts about Ant :

1. Ant is a Java based build tool which enables you to build, package,
deploy, test, document, etc.    You can build anything with Ant, but
it is most widely used at building Java projects (there are hordes of
built in Ant tasks which will automatically handle repetitive tasks
which you typically perform in building / packaging / deploying /
testing or generating documentation for Java, J2EE, etc).

2. Ant has built in support for many of the activities you must
perform in building a J2EE application (e.g. WISE).   A typical Ant
build file is going to be a fraction of the size of a corresponding
Makefile (or more likely multiple Makefiles) and will be at least 10
times faster at building the system.   It currently takes 6 seconds to
compile all of the Wise order Java files (211 Java files in 31
different packages at current) on my laptop.

3. Ant has become an industry standard for Java projects.   Some of
the Java products / projects which use Ant to build their Java related
subsystems.   Sun list usage of Ant under its "Best Practices" Area
(see http://dcb.sun.com/practices/profiles/ant.jsp)
   -Various products from Sun Microsystems (the J2EE suite itself uses Ant)
   -Various products from Apache : Xerces, Xalan, Cocoon, Tomcat, etc.
   -Various other popular and widely used Java products like JBOSS, etc.

4. Ant does not preclude the use of Make.  In our current scenario, we
will have a Makefile which kicks off Ant.    Ant should be the tool of
choice when building Java subsystems.

5. Ant is completely cross platform.  It enables you to build on any
platform without changing a single line of the build file.  Contrast
this with IBM's version of Make (which is directed at a very specific
platform).

It is a common misconception that just because a product is "open
source" it is "not supported".   In this day and age - companies like
Verizon cannot discount products which are open source.  Currently
many of the industry standard building blocks are actually open source
products (take Xerces or Xalan for instance - both of which we are
using on the WISE project).   At this point - BEA even ships Weblogic
with a version of Xerces built in (Xerces is an open source XML parser
from the Apache Software foundation).    It is the most widely used
XML parser out there - and it is completely open source (and free).
Off the top of my head, I don't know of an XML parser you can actually
pay for (they're all free).  Another industry standard open source
tool is JUnit (a testing framework).  You'd be hard pressed to find
any "best practices" literature out there that didn't recommend using
JUnit for large Java projects.   Tomcat is the most widely used
Servlet container (and in fact, is the reference implementation of
Sun's Servlet & JSP specifications).

Many of the Open Source companies (like RedHat) make their money by
selling support contracts for their open source tools (again - just
because its open source does not mean its "unsupported").  In the case
of Ant, Xerces or Junit, I can't imagine actually purchasing one of
these contracts because there is so much freely available community
support for these products via newsgroups and mailing lists (I posted
a question to the Ant mailing list on Friday evening and had 11
replies by Saturday morning).

One of the best things about Ant is its cross platform nature.  Since
WISE is written in Java, the WISE development team typically does
daily development on NT/Win2k (Java is cross platform at the binary
level - this means you can take something compiled on NT/Win2k and run
it on AIX or any other platform).   We are constantly shifting back
and forth between the development environment (NT/Win2k) and the
deployment environment (AIX).   With Ant - nothing changes.   We use
the same build.xml file to build the system on NT/Win2k as we use to
build it on AIX (this is not the case with IBM's version of Make).

Don't get me wrong - I think standards are extremely important
(especially in large organization), but in order for them to be
effective, we must periodically evaluate policies and in certain
instances adapt them to the changing times.    The Wise build process
is like driving a nail into a board.   Ant is the hammer and Make is a
big rock.   Sure you can use the Rock to drive the nail, but it would
be a lot easier if you were allowed to use the more appropriate tool.

Here's a quote from the following article
(http://www.sys-con.com/java/archives/0606/ford/index.html - which
compares Ant and Make) :

   "The make file syntax must be in an exact format, and the format is
   specific to the version of the make utility. Different implementations
   of make utilities require slightly different syntax. As you can see,
   the syntax of the make file is somewhat daunting - it's like learning
   an entirely new development language. The make file also defines
   special wildcards (like the "@&&!" wildcard in Listing 1). The bigger
   concern is that make utilities aren't well optimized for Java. For
   example, Java has very special requirements for package and directory
   structures. Make utilities don't natively understand this
   relationship. This isn't to say they haven't been used quite
   successfully for Java development. However, what was really needed was
   a new make utility that understands Java. That's where Ant enters the
   picture"


Here are some relevant links :

- Sun lists Ant as the preferred build tool in the  "Best Practices"area of
its Site:
		 http://dcb.sun.com/practices/profiles/ant.jsp

- Ant's Home Page : http://jakarta.apache.org/ant/

- Article on uing Ant & JUnit :
http://www-106.ibm.com/developerworks/library/j-ant/?dwzone=java

- JavaWorld Article on Ant:
http://www.javaworld.com/javaworld/jw-10-2000/jw-1020-ant.html




-----Original Message-----
From: Robert J. Clark [mailto:clark@sitraka.com]
Sent: Monday, June 11, 2001 5:25 PM
To: ant-dev@jakarta.apache.org
Subject: Re: Need Ammo in Make vs. Ant argument...


On Sat, 9 Jun 2001 15:48:27 +1000  Tim Vernum <Tim.Vernum@macquarie.com.au>
wrote:

> From: Lance Hankins [mailto:lhankins@focus-technologies.com]
>
> > Any ammunition will be greatly appreciated :)
>
> I can get you some research (that I think was from Sun) that showed
> that for a large system, 10% of the code was in the build process.

I would also be interested in reading this if it is available. Drop
me a line offlist if you would like.

> But any metric of a large in house development system should give
> similar results.

This is what we are seeing here as well.

> When you realise the size of the work done by the build engineers
> (and management rarely does) you have to stop and ask
       ^^^^^^^^^^^^^^^^^^^^^^
You don't say :-)

I am fortunate in that one result of the lack of attention
to the build infrastructure is that I can pretty much choose
any tool that can reasonably be shown to do the job. We use a
mixture of Ant and make files here.

I have been reading with interest the comments from people who
are interested in compiling native code with Ant and have often
thought about trying it in my Copious Free Time(tm).

However, before I get to that I will probably try getting Ant to
run as a server. Our builds are distributed over several different
systems and I have never been happy with the solutions we have
currently implemented.

I have not yet convinced myself that Ant is the right tool to replace
that part of the build system, but I have long since realized that it
is better than make for building all the Java code.

- Rob

--
Robert J. Clark                   Sitraka Software
JProbe Developer                  http://www.sitraka.com
clark@sitraka.com




Mime
View raw message