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:[EMAIL PROTECTED] Sent: Monday, June 11, 2001 5:25 PM To: [EMAIL PROTECTED] Subject: Re: Need Ammo in Make vs. Ant argument... On Sat, 9 Jun 2001 15:48:27 +1000 Tim Vernum <[EMAIL PROTECTED]> wrote: > From: Lance Hankins [mailto:[EMAIL PROTECTED] > > > 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 [EMAIL PROTECTED]
