diff --git a/docs/ant_in_anger.html b/docs/ant_in_anger.html index da6bef7f1..596b8db77 100644 --- a/docs/ant_in_anger.html +++ b/docs/ant_in_anger.html @@ -12,7 +12,7 @@
<target name="clean" depends="clean-intf, clean-impl"> </target> @@ -121,6 +121,11 @@ impl subdirectories from a parent directory <ant dir="impl" target="clean" /> </target>+If you give targets a description tag, then calling ant +-projecthelp will list all tasks with their description as 'main targets', and +all tasks without a description as subtargets. Describing all your +entry points is therefore very useful, even before a project becomes big and complicated. +
This difference between platforms (indeed, the whole java classpath paradigm) can cause hours of fun. @@ -242,8 +253,13 @@ 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 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 +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), @@ -254,7 +270,7 @@ directories to see a disastrous example of this).
Ant's policy on case sensitivity is whatever the underlying file system -implements *VERIFY*, and its handling of file extensions is that *.jav does not +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". @@ -336,8 +352,8 @@ file with tight access control is slightly better. The 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. If DAV is your -required upload mechanism, why not take up the challenge? +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.
@@ -351,15 +367,19 @@ project and the rest of the ant community.
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.
-
+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.
Directory Structures
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.
+starting points. All the jakarta projects follow a roughly similar
+style, which makes it easy to navigate around one form one project to
+another, and easy to clean up when desired.
+ +Javadoc output can be directed to a doc/ folder beneath build/, or to doc/javadoc.
+The only way to retain control over a fairly loosely integrated +collection of projects is to have a fully automated build +and test process which verifies that everything is still compatible. Sam +Ruby runs one for all the apache java libraries and emails everyone when +something breaks; your own project may be able to make use of +Cruise Control for +an automated, continuous, background build process.
@@ -517,7 +561,62 @@ consider routing it to an email address you don't use for much else. And
don't make everyone on the team subscribe; it can be too much of a
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
+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 +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 +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 +the war file (with datestamp and buildstamp) to an archive directory, +clean up the current deployed version of the war and then install the +new version. Because bluestone restarted JVMs on demand, this script was +all you needed for web service deployment. On the systems behind the +firewall, we upped the ante in the deployment process by using the ftp +task to copy out the war and build files, then the telnet task to +remotely invoke the build file. The result was we had automated +recompile and redeploy to local servers from inside our IDE (Jedit) or +the command line, which was simply invalualbe. + +
+ +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 functionality, +ability to spawn executables and all the other trouble spots +, the install script could automatically do +a system health test 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.
Tips and Tricks
@@ -530,7 +629,7 @@ Tips and Tricks
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
+cellphones.
+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. So you can actually have a suite of utility targets -"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 +build files call with their own settings. If you can achive this then +you are definately making your way up the software maturity ladder. 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 that of the caller, now you just have to remember to set +inheritall="false" on all uses of the ant task. + +
Debug/release switching can be handled with separate initialisation targets called before the compile tasks which define the appropriate -properties. +properties. Antcall is the trick here, as it allows you to have two paths +of property initialisation in a build file.
Internal targets should be used to structure the process @@ -773,7 +916,7 @@ before acting.
+ +You also need some kind of change control process, to resist +uncontrolled feature creep. Bugzilla is a simple and low cost tool for +this, using ant and a continuous test process enables a rapid evolution of code +to adapt to those changes which are inevitable.
Copyright © 2000 Apache Software Foundation. All rights -Reserved.
+ +Copyright © 2000, 2001 Apache Software Foundation. All rights +Reserved.
+