From 6b21c7c998d7522b640c956e51aab2b6c89e21d4 Mon Sep 17 00:00:00 2001 From: Antoine Levy-Lambert Date: Wed, 16 Mar 2005 06:03:52 +0000 Subject: [PATCH] spelling patch by Kev Jackson git-svn-id: https://svn.apache.org/repos/asf/ant/core/trunk@277995 13f79535-47bb-0310-9956-ffa450edef68 --- docs/ant_in_anger.html | 338 +++++++++++++++++------------------------ 1 file changed, 136 insertions(+), 202 deletions(-) diff --git a/docs/ant_in_anger.html b/docs/ant_in_anger.html index e840203a3..7ac79b195 100644 --- a/docs/ant_in_anger.html +++ b/docs/ant_in_anger.html @@ -13,7 +13,7 @@

Steve Loughran
-Last updated 2002-11-09 +Last updated 2005-03-16

@@ -22,15 +22,15 @@ Last updated 2002-11-09 Apache Ant - can be an invaluable tool in a team development process -or it can + can be an invaluable tool in a team development process - or it can be yet another source of problems in that ongoing crises we call development . This document contains some strategies and tactics for making the most of Ant. It is moderately frivolous in places, and lacks almost any actual -examples of Ant xml. The lack of examples is entirely deliberate -it +examples of Ant XML. The lack of examples is entirely deliberate - it keeps document maintenance costs down. Most of the concepts covered -don't need the detail about XML representations, as it is processes we -are concerned about, not syntax. Finally, please be aware that the +don't need the detail provided by XML representations, as it is the processes we +are concerned about, not the syntax. Finally, please be aware that the comments here are only suggestions which need to be customised to meet your own needs, not strict rules about what should and should not be done. @@ -44,10 +44,10 @@ document covers:
  • Team efforts, usually with the petulant prima-donnas all us Java programmers become once we realise how much in demand we are. -
  • A fairly distributed development team -spread across locations and +
  • A fairly distributed development team - spread across locations and maybe time zones. -
  • Separate sub projects -from separate beans in a big +
  • Separate sub projects - from separate beans in a big enterprise application to separate enterprise applications which need to be vaguely aware of each other. @@ -58,7 +58,6 @@ late next century the date coming up from below.
  • Everyone is struggling to keep up with platform and tool evolution.
  • Extensive use of external libraries, both open and closed source. - What that all means is that there is no time to spend getting things @@ -74,21 +73,19 @@ the other problems.

    Clarify what you want Ant to do

    - Ant is not a silver bullet. It is just another rusty bullet in the armory of development tools available at your disposal. Its primary purpose is to accelerate the construction and deployment of Java projects. You could certainly extend Ant to do anything Java makes possible: it is easy to imagine writing an image processing task to help in web site deployment by shrinking and recompressing jpeg files, for example. But that would be pushing the boundary of -what Ant is really intended to do -so should be considered with care. - -

    +what Ant is really intended to do - so should be considered with care. +

    Ant is also a great adjunct to an IDE; a way of doing all the housekeeping of deployment and for clean, automated builds. But a good modern IDE is a -productivity tool in its own right -one you should consider keeping using. Ant -just lets you give the teams somewhat more freedom in IDE choice -"you can +productivity tool in its own right - one you should continue to use. Ant +just lets you give the teams somewhat more freedom in IDE choice - "you can use whatever you want in development, but Ant for the deployment builds" Now that many modern open source and commercial IDEs include Ant support (including jEdit, Forte, Eclipse and IDEA), @@ -99,18 +96,17 @@ build process integrated into the tool. Define standard targets - When you have multiple sub projects, define a standard set of targets. Projects with a split between interface and implementation jar files -could consider impl and intf targets -with separate -debug-impland debug-intf targets for the debug version. +could consider impl and intf targets - with separate +debug-impl and debug-intf targets for the debug version. And of course, the ubiquitous clean target. -

    +

    With standard target names, it is easy to build encompassing Ant build files which just hand off the work to the classes below using the -<ant> +ant task. For example. the clean target could be handed down to the intf and impl subdirectories from a parent directory @@ -138,31 +134,29 @@ If Ant does not do what you want, you can use the exec and java tasks or inline scripting to extend it. In a -project with many build.xml files, you soon find that having a single +project with many build.xml files, you soon find that having a single central place for implementing the functionality keeps maintenance overhead down. Implementing task extensions through Java code seems extra effort at first, but gives extra benefits:-

    -In a way, it is it this decoupling of functionality, "the tasks", from +In a way, it is this decoupling of functionality, "the tasks", from the declaration of use, "the build file", that has helped Ant succeed. If you have to get something complex done in Make or an IDE, you have a hairy makefile that everyone is scared of, or an IDE configuration that is invariably very brittle. But an Ant task is reusable and shareable among all Ant users. Many of the core and optional tasks in Ant today, tasks you do or will come to depend on, were written by people trying to -solve their own pressing problems. +solve their own pressing problems.

    Embrace Automated Testing @@ -170,7 +164,6 @@ Embrace Automated Testing (alternatively "recriminate early, recriminate often")

    - Ant lets you call JUnit tasks, which unit test the code your team has written. Automated testing may seem like extra work at first, but JUnit makes writing unit tests so @@ -178,12 +171,10 @@ easy that you have almost no reason not to. Invest the time in learning how to use JUnit, write the test cases, and integrate them in a 'test' target from Ant so that your daily or hourly team build can have the tests applied automatically. One of the free to download chapters of -Java Development with Ant +Java Development with Ant shows you how to use JUnit from inside Ant.

    - - Once you add a way to fetch code from the SCM system, either as an Ant task, in some shell script or batch file or via some continuous integration tool. the integration test code can be a pure Ant task run @@ -194,10 +185,9 @@ used even though no developer would willingly use that configuration given the choice.

    - System tests are harder to automate than unit tests, but if you can -write java code to stress large portions of the system -even if the code -can not run as JUnit tasks- then the java +write java code to stress large portions of the system - even if the code +can not run as JUnit tasks - then the java task can be used to invoke them. It is best to specify that you want a new JVM for these tests, so that a significant crash does not break the full build. The Junit extensions such as @@ -205,36 +195,33 @@ full build. The Junit extensions such as Cactus for J2EE and servlet testing help to expand the testing framework. To test properly you will still need to invest a lot of effort in getting these to work with your project, and -deriving great unit, system and regression tests -but your customers will love +deriving great unit, system and regression tests - but your customers will love you for shipping software that works. -

    Learn to Use and love the add-ons to Ant

    The Ant distribution is not the limit of the Ant universe, it is only the beginning. Look at the - + External Tools and Tasks page - for an up to date list. Here are some of them that . + for an up to date list. Here are some of them that . -

    Cross Platform Ant

    - Ant is the best foundation for cross platform Java development and testing to date. But if you are not paying attention, it is possible to -produce build files which only work on one platform -or indeed, one +produce build files which only work on one platform - or indeed, one single workstation.

    - The common barriers to cross-platform Ant are the use of command line tools (exec tasks) which are not portable, path issues, and hard coding in the location of things. -

    Command Line apps: Exec/ +

    Command Line apps: Exec / Apply

    The trouble with external invocation is that not all functions are found -cross platform, and those that are often have different names -DOS -descendants often expect .exe or .bat at the end of files. That can be +cross platform, and those that are often have different names - DOS +descendants often expect .exe or .bat at the end of files. That can be bad if you explicitly include the extension in the naming of the command (don't!), good when it lets you keep the unix and DOS versions of an executable in the same bin directory of the project without name clashes arising.

    - Both the command line invocation tasks let you specify which platform you want the code to run on, so you could write different tasks for each platform you are targeting. Alternatively, the platform differences @@ -295,44 +278,41 @@ This difference between platforms (indeed, the whole java classpath paradigm) can cause hours of fun.

    - Ant reduces path problems; but does not eliminate them entirely. You need to put in some effort too. The rules for handling path names are that 'DOS-like pathnames are handled', 'Unix like paths are handled'. Disk drives -'C:'- are handled on DOS-based boxes, but placing them in -the build.xml file ruins all chances of portability. Relative file paths -are much more portable. Semicolons work as path separators -a fact which +the build.xml file ruins all chances of portability. Relative file paths +are much more portable. Semicolons work as path separators - a fact which is useful if your Ant invocation wrapper includes a list of jars as a defined property in the command line. In the build files you may find it better to build a classpath by listing individual files (using location= -attributes), or by including a fileset of *.jar in the classpath +attributes), or by including a fileset of *.jar in the classpath definition.

    There is also the PathConvert task which can put a fully resolved path into a property. Why do that? Because then -you can use that path in other ways -such as pass it as a parameter to +you can use that path in other ways - such as pass it as a parameter to some application you are calling, or use the replace task to patch it into a localised shell script or batch file.

    Note that DOS descended file systems are case insensitive (apart from the obscure aberration of the WinNT POSIX subsystem run against NTFS), and that Windows pretends that all file extensions with four or more -letters are also three letter extensions (try DELETE *.jav in your java +letters are also three letter extensions (try DELETE *.jav in your java directories to see a disastrous example of this).

    - Ant's policy on case sensitivity is whatever the underlying file system -implements, and its handling of file extensions is that *.jav does not -find any .java files. The Java compiler is of course case sensitive -you can +implements, and its handling of file extensions is that *.jav does not +find any .java files. The Java compiler is of course case sensitive - you can not have a class 'ExampleThree' implemented in "examplethree.java".

    - -Some tasks only work on one platform - +Some tasks only work on one platform - Chmod being a classic example. These tasks usually result in just a -warning message on an unsupported platform -the rest of the target's +warning message on an unsupported platform - the rest of the target's tasks will still be called. Other tasks degrade their functionality on platforms or Java versions. In particular, any task which adjusts the timestamp of files can not do so properly on Java 1.1. Tasks which can @@ -341,63 +321,56 @@ href="manual/CoreTasks/touch.html">Touch and Win32 platforms from -ActiveState. A Perl file with .pl extension, with the usual Unix +"http://www.activestate.com/Products/ActivePerl/">Win32 platforms from +ActiveState. A Perl file with .pl extension, the usual Unix path to perl on the line 1 comment and marked as executable can be run on Windows, OS/2 and Unix and hence called from Ant without issues. The perl code can be left to resolve its own platform issues. Don't forget to set the line endings of the file to the appropriate platform when you redistribute Perl code; <fixCRLF> +href="manual/CoreTasks/fixcrlf.html">fixCRLF can do that for you.

    Team Development Processes

    - Even if each team member is allowed their choice of IDE/editor, or even OS, you need to set a baseline of functionality on each box. In particular, the JDKs and jars need to be in perfect sync. Ideally pick the latest stable Java/JDK version available on all developer/target systems and stick with it for a while. Consider assigning one person to -be the contact point for all tools coming in -particularly open source +be the contact point for all tools coming in - particularly open source tools when a new build is available on a nightly basis. Unless needed, these tools should only really be updated monthly, or when a formal release is made.

    - Another good tactic is to use a unified directory tree, and add on extra tools inside that tree. All references can be made relative to the tree. If team members are expected to add a directory in the project to their -path, then command line tools can be included there -including those +path, then command line tools can be included there - including those invoked by Ant exec tasks. Put everything under source code control and you have a one stop shop for getting a build/execute environment purely from CVS or your equivalent. -

    Deploying with Ant

    - One big difference between Ant and older tools such as Make is that the processes for deploying Java to remote sites are reasonably well evolved in Ant. That is because we all have to do it these days, so many people have put in the effort to make the tasks easier.

    - Ant can Jar, Tar or Tar or Zip files for deployment, while the War task extends the jar task for better servlet deployment. -Jlink is a +Jlink is a jar generation file which lets you merge multiple sub jars. This is ideal for a build process in which separate jars are generated by sub projects, yet the final output is a merged jar. - -The ftp task lets you move stuff up to a -server. Beware of putting the ftp password in the build file -a property +The ftp task lets you move stuff up to a +server. Beware of putting the ftp password in the build file - a property file with tight access control is slightly better. The FixCRLF task is often a useful interim step if +"manual/CoreTasks/fixcrlf.html">FixCRLF task is often a useful interim step if you need to ensure that files have Unix file extensions before upload. A WebDav task has long been discussed, which would provide a more secure upload to web servers, but it is still in the todo list. Rumour has it that there is such a task in the jakarta-slide libraries. With MacOS X, Linux and Windows XP all supporting WebDAV file systems, you may even be able -to use <copy> to deploy +to use copy to deploy though a firewall.

    - -EJB deployment is aided by the ejb tasks, +EJB deployment is aided by the ejb tasks, while the <serverdeploy> +href="manual/OptionalTasks/serverdeploy.html">serverdeploy suite can deploy to multiple servers. The popularity of Ant has encouraged vendors to produce their own deployment tasks which they redistribute with their servers. For example, the Tomcat4.1 installation includes tasks to deploy, undeploy and reload web applications.

    - Finally, there are of course the fallbacks of just copying files to a -destination using Copy and Copydir , or just sending them to a person or -process using Mail or the attachment +destination using Copy and Copydir , or just sending them to a person or +process using Mail or the attachment aware MimeMail. In one project our team even used Ant to build CD images through a build followed by a long set of Copy tasks, which worked surprisingly well, certainly @@ -450,7 +419,7 @@ through SSH. How you structure your directory tree is very dependent upon the project. Here are some directory layout patterns which can be used as starting points. All the jakarta projects follow a roughly similar -style, which makes it easy to navigate around one form one project to +style, which makes it easy to navigate around one from one project to another, and easy to clean up when desired.

    Simple Project

    @@ -460,7 +429,7 @@ The project contains sub directories bin - common binaries, scripts -put this on the path. + common binaries, scripts - put this on the path. @@ -501,43 +470,38 @@ The project contains sub directories The bin, lib, doc and src directories should be under source code control. Slight variations include an extra tree of content to be included in the -distribution jars -inf files, images, etc. These can go under source -too, with a metadata directory for web.xml and similar -manifests, and a web folder for web content -JSP, html, images +distribution jars - inf files, images, etc. These can go under source +too, with a metadata directory for web.xml and similar +manifests, and a web folder for web content - JSP, html, images and so on. Keeping the content in this folder (or sub hierarchy) together makes it easier to test links before deployment. The actual -production of a deployment image -such as a war file- can be left to the +production of a deployment image, such as a war file, can be left to the appropriate Ant task: there is no need to completely model your source tree upon the deployment hierarchy.

    - Javadoc output can be -directed to a doc/ folder beneath build/, or to doc/javadoc. +directed to a doc/ folder beneath build/, or to doc/javadoc.

    Interface and Implementation split

    If the interface is split from the implementation code then this can be supported with minor changes just by having a separate build path for -the interface directory -or better still just in the jar construction: +the interface directory - or better still just in the jar construction: one jar for interface and one jar for implementation. -

    Loosely Coupled Sub Projects

    In the loosely coupled approach multiple projects can have their own copy of the tree, with their own source code access rights. One difference to consider is only having one instance of the bin and -lib directories across all projects. This is sometimes good -it helps -keep copies of xerces.jar in sync, and sometimes bad -it can update +lib directories across all projects. This is sometimes good - it helps +keep copies of xerces.jar in sync, and sometimes bad - it can update foundational jar files before unit testing is complete.

    - To still have a single build across the sub projects, use parent -build.xml files which call down into the sub projects. - +build.xml files which call down into the sub projects.

    - This style works well if different teams have different code access/commitment rights. The risk is that by giving extra leeway to the sub projects, you can end up with incompatible source, libraries, build @@ -555,16 +519,15 @@ an automated, continuous, background build process. Tightly coupled projects have all the source in the same tree; different projects own different subdirectories. Build files can be moved down to -those subdirectories (say src/com/iseran/core and src/com/iseran/extras), -or kept at the top -with independent build files named core.xml and -extras.xml +those subdirectories (say src/com/iseran/core and src/com/iseran/extras), +or kept at the top - with independent build files named core.xml and +extras.xml.

    - This project style works well if everyone trusts each other and the sub projects are not too huge or complex. The risk is that a split to a more loosely coupled design will become a requirement as the projects -progress -but by the time this is realised schedule pressure and +progress - but by the time this is realised schedule pressure and intertwined build files make executing the split well nigh impossible. If that happens then just keep with it until there is the time to refactor the project directory structures. @@ -576,34 +539,31 @@ refactor the project directory structures. Once you start using Ant, you should have a policy on when and how the -team updates their copies. A simple policy is "every official release +team updates their copies. A simple policy is "every official release after whatever high stress milestone has pushed all unimportant tasks -(like sleep and seeing daylight) on the back burner". This insulates you +(like sleep and seeing daylight) on the back burner". This insulates you from the changes and occasional instabilities that Ant goes through during development. Its main disadvantage is that it isolates you from the new tasks and features that Ant is constantly adding.

    - -Often an update will require changes to the build.xml files. Most +Often an update will require changes to the build.xml files. Most changes are intended to be backwards compatible, but sometimes an incompatible change turns out to be necessary. That is why doing the update in the lull after a big -milestone is important. It is also why including ant.jar and related +milestone is important. It is also why including ant.jar and related files in the CVS tree helps ensure that old versions of your software can be still be built.

    - The most aggressive strategy is to get a weekly or daily snapshot of the ant source, build it up and use it. This forces you to tweak the -build.xml files more regularly, as new tasks and attributes can take +build.xml files more regularly, as new tasks and attributes can take while to stabilise. You really have to want the new features, enjoy gratuitous extra work or take pleasure in upsetting your colleagues to take this approach.

    - Once you start extending Ant with new tasks, it suddenly becomes much more tempting to pull down regular builds. The most recent Ant builds are invariably the best platform for writing your extensions, as you @@ -611,10 +571,10 @@ can take advantage of the regular enhancements to the foundational classes. It also prevents you from wasting time working on something which has already been done. A newly submitted task to do something complex such as talk to EJB engines, SOAP servers or just convert a text -file to uppercase may be almost exactly what you need -so take it, +file to uppercase may be almost exactly what you need - so take it, enhance it and offer up the enhancements to the rest of the world. This is certainly better than starting work on your 'text case converter' -task on Ant 0.8 in isolation, announcing its existence six months latter +task on Ant 0.8 in isolation, announcing its existence six months later and discovering that instead of adulation all you get are helpful pointers to the existing implementation. The final benefit of being involved with the process is that it makes it easier for your tasks to @@ -624,9 +584,8 @@ If that happens you can revert to an official Ant release, and get on with all the other crises.

    - You should also get on the dev mailing list +"mailto:dev-subscribe@ant.apache.org">dev mailing list , as it is where the other developers post their work, problems and experience. The volume can be quite high: 40+ messages a day, so consider routing it to an email address you don't use for much else. And @@ -638,30 +597,27 @@ distraction. Installing with Ant. - Because Ant can read environment variables, copy, unzip and delete files and make java and OS calls, it can be used for simple installation tasks. For example, an installer for tomcat could extract the -environment variable TOMCAT_HOME, stop tomcat running, and copy a war -file to TOMCAT_HOME/webapps. It could even start tomcat again, but the +environment variable TOMCAT_HOME, stop tomcat running, and copy a war +file to TOMCAT_HOME/webapps. It could even start tomcat again, but the build wouldn't complete until tomcat exited, which is probably not what was wanted.

    - The advantage of using Ant is firstly that the same install targets can be used from your local build files (via an ant invocation -of the install.xml file), and secondly that a basic install target is +of the install.xml file), and secondly that a basic install target is quite easy to write. The disadvantages of this approach are that the destination must have an up to date version of Ant correctly -pre-installed, and Ant doesn't allow you to handle failures well -and a +pre-installed, and Ant doesn't allow you to handle failures well - and a good installer is all about handling when things go wrong, from files being in use to jar versions being different. This means that Ant is not suited for shrink wrapped software, but it does work for deployment and installation to your local servers.

    - One major build project I was involved in had an Ant install build file for the bluestone application server, which would shutdown all four instances of the app server on a single machine, copy the new version of @@ -678,7 +634,6 @@ on your IDE toolbar to build, unit test, deploy and then functional test your webapp.

    - One extra trick I added later was a junit test case to run through the install check list. With tests to verify access permissions on network drives, approximate clock synchronisation between servers, DNS @@ -688,7 +643,6 @@ during install time and report problems. [The same tests could also be invoked from a JMX MBean, but that's another story].

    - So, Ant is not a substitute for a real installer tool, except in the special case of servers you control, but in that context it does let you integrate remote installation with your build. @@ -703,7 +657,7 @@ Tips and Tricks get

    -The <get> task can fetch any URL, so be used +The get task can fetch any URL, so be used to trigger remote server side code during the build process, from remote server restarts to sending SMS/pager messages to the developer cellphones. @@ -712,8 +666,7 @@ cellphones. i18n
    - -Internationalisation is always trouble. Ant helps here with the native2ascii task which can escape out all non ascii characters into unicode. You can use this to write java files which include strings (and indeed comments) in your own non-ASCII @@ -725,7 +678,7 @@ Use Property Files
    Use external property files to keep per-user settings out the build -files -especially passwords. Property files can also be used to +files - especially passwords. Property files can also be used to dynamically set a number of properties based on the value of a single property, simply by dynamically generating the property filename from the source property. They can also be used as a source of constants across @@ -735,12 +688,12 @@ multiple build files. Faster compiles with Jikes
    -The jikes compiler is usually much +The jikes compiler is usually much faster than javac, does dependency checking and has better error messages (usually). Get it. Then set -build.compiler to "jikes" for it to be used in your build files. +build.compiler to "jikes" for it to be used in your build files. Doing this explicitly in your build files is a bit dubious as it requires the -whole team (and sub projects) to be using jikes too -something you can only +whole team (and sub projects) to be using jikes too - something you can only control in small, closed source projects. But if you set ANT_OPTS = -Dbuild.compiler=jikes in your environment, then all your builds on your system will use @@ -748,7 +701,7 @@ Jikes automatically, while others can choose their own compiler, or let ant choose whichever is appropriate for the current version of Java.
    -#include targets to simplify multi build.xml projects +#include targets to simplify multi build.xml projects
    You can import XML files into a build file using the XML parser itself. @@ -760,7 +713,6 @@ equivalent to the #include mechanism of the 'legacy' languages C and C++.

    - There are two inclusion mechanisms, an ugly one for all parsers and a clean one. The ugly method is the only one that was available on Ant1.5 and earlier:- @@ -788,32 +740,29 @@ takes place after the main build file is parsed, during execution, whereas XML entity expansion is handled during the parsing process.

    - The <import> task does powerful things, such as let you override targets, and use ant properties to name the location of the file to import. Consult the documentation for the specifics of these features.

    - Before you go overboard with using XML inclusion, note that the -<ant> task lets you call any target in any other build -file -with all your property settings propagating down to that target. +ant task lets you call any target in any other build +file - with all your property settings propagating down to that target. So you can actually have a suite of utility targets --"deploy-to-stack-a", "email-to-team", "cleanup-installation" which can +- "deploy-to-stack-a", "email-to-team", "cleanup-installation" which can be called from any of your main build files, perhaps with subtly changed parameters. Indeed, after a couple of projects you may be able to create a re-usable core build file which contains the core targets of a basic -Java development project -compile, debug, deploy- which project specific +Java development project - compile, debug, deploy - which project specific build files call with their own settings. If you can achieve this then you are definitely making your way up the software maturity ladder. With a bit of work you may progress from being a SEI CMM Level 0 organisation -"Individual Heroics are not enough" to SEI CMM Level 1, "Projects only -succeed due to individual heroics" +"Individual Heroics are not enough" to SEI CMM Level 1, "Projects only +succeed due to individual heroics"

    - -NB, <ant> copies all your properties unless the +NB, ant copies all your properties unless the inheritall attribute is set to false. Before that attribute existed you had to carefully name all property definitions in all build files to prevent unintentional overwriting of the invoked property by @@ -826,52 +775,48 @@ Implement complex Ant builds through XSL

    XSLT can be used to dynamically generate build.xml files from a source -xml file, with the <xslt> task controlling +xml file, with the xslt task controlling the transform. This is the current recommended strategy for creating complex build files dynamically. However, its use is still apparently -quite rare -which means you will be on the bleeding edge of technology. +quite rare - which means you will be on the bleeding edge of technology.
    Change the invocation scripts
    -By writing your own invocation script -using the DOS, Unix or Perl -script as a starting point- you can modify Ant's settings and behavior for an +By writing your own invocation script - using the DOS, Unix or Perl +script as a starting point - you can modify Ant's settings and behavior for an individual project. For example, you can use an alternate variable to -ANT_HOME as the base, extend the classpath differently, or dynamically -create a new command line property 'project.interfaces' from all .jar +ANT_HOME as the base, extend the classpath differently, or dynamically +create a new command line property "project.interfaces" from all .jar files in an interfaces directory.

    - Having a custom invocation script which runs off a CVS controlled -library tree under PROJECT_HOME also lets you control Ant versions -across the team -developers can have other copies of Ant if they want, +library tree under PROJECT_HOME also lets you control Ant versions +across the team - developers can have other copies of Ant if they want, but the CVS tree always contains the jar set used to build your project.

    - You can also write wrapper scripts which invoke the existing Ant scripts. This is an easy way to extend them. The wrapper scripts can add -extra definitions and name explicit targets, redefine ANT_HOME and -generally make development easier. Note that "ant" in Windows is really -"ant.bat", so should be invoked from another batch file with a "CALL -ant" statement -otherwise it never returns to your wrapper. +extra definitions and name explicit targets, redefine ANT_HOME and +generally make development easier. Note that "ant" in Windows is really +"ant.bat", so should be invoked from another batch file with a "CALL +ant" statement - otherwise it never returns to your wrapper.

    Write all code so that it can be called from Ant
    - This seems a bit strange and idealistic, but what it means is that you should write all your java code as if it may be called as a library at some point in -future. So do not place calls to System.exit() deep in the code -if you +future. So do not place calls to System.exit() deep in the code - if you want to exit a few functions in, raise an exception instead and have main() deal with it.

    - Moving one step further, consider proving an Ant Task interface to the code as a secondary, primary or even sole interface to the functionality. Ant actually makes a great bootloader for Java apps as it @@ -880,8 +825,6 @@ preamble and postamble work. Some projects, such as XDoclet only run under Ant, because that is the right place to be. - -