nico 01/02/10 15:27:29
Modified: docs Tag: ANT_13_BRANCH ant_in_anger.html
Log:
Fixed links to point to the new manual
Revision Changes Path
No revision
No revision
1.2.2.1 +22 -22 jakarta-ant/docs/ant_in_anger.html
Index: ant_in_anger.html
===================================================================
RCS file: /home/cvs/jakarta-ant/docs/ant_in_anger.html,v
retrieving revision 1.2
retrieving revision 1.2.2.1
diff -u -r1.2 -r1.2.2.1
--- ant_in_anger.html 2001/01/29 01:19:59 1.2
+++ ant_in_anger.html 2001/02/10 23:27:28 1.2.2.1
@@ -106,7 +106,7 @@
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
-<a href="index.html#ant">ant</a>
+<a href="manual/CoreTasks/ant.html">ant</a>
task. For example. the clean target could be handed down to the intf and
impl subdirectories from a parent directory
@@ -126,9 +126,9 @@
</h3>
If ant does not do what you want, you can use the
-<a href="index.html#exec">exec</a> and
-<a href="index.html#java">java</a> tasks or
-<a href="index.html#script">inline scripting</a> to extend it. In a
+<a href="manual/CoreTasks/exec.html">exec</a> and
+<a href="manual/CoreTasks/java.html">java</a> tasks or
+<a href="manual/OptionalTasks/script.html">inline scripting</a> to extend
it. In a
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
@@ -153,7 +153,7 @@
<b>(alternatively "recriminate early, recriminate often")</b>
<p>
-Ant lets you call <a href="junit.html">JUnit</a> tasks, which unit test
+Ant lets you call <a href="manual/OptionalTasks/junit.html">JUnit</a> 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 easy that you have
almost no reason not to. Invest the time in learning how to use
@@ -175,7 +175,7 @@
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 <a href= "index.html#java">java</a>
+can not run as JUnit tasks- then the <a href=
"manual/CoreTasks/java.html">java</a>
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.
@@ -198,8 +198,8 @@
tools (exec tasks) which are not portable, path issues, and hard coding
in the location of things.
-<h3>Command Line apps: <a href="index.html#exec">Exec</a>/ <a href=
-"index.html#execon">ExecOn</a></h3>
+<h3>Command Line apps: <a href="manual/CoreTasks/exec.html">Exec</a>/ <a
href=
+"manual/CoreTasks/execon.html">ExecOn</a></h3>
The trouble with external invocation is that not all functions are found
cross platform, and those that are often have different names -DOS
@@ -260,14 +260,14 @@
<p>
-Some tasks only work on one platform -<a href= "index.html#chmod">
+Some tasks only work on one platform -<a href= "manual/CoreTasks/chmod.html">
Chmod</a> being a classic example. These tasks usually result in just a
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
-do that - <a href="index.html#get">Get<a>, <a
-href="index.html#touch">Touch</a> and <A href="index.html#unzip">
+do that - <a href="manual/CoreTasks/get.html">Get<a>, <a
+href="manual/CoreTasks/touch.html">Touch</a> and <A
href="manual/CoreTasks/unzip.html">
Unjar/Unwar/Unzip</a> for example, degrade their functionality on
Java1.1, usually resorting to the current timestamp instead.
@@ -318,14 +318,14 @@
many people have put in the effort to make the tasks easier.
<p>
-Ant can <a href="index.html#jar">Jar</a>, <a href= "index.html#tar">
-Tar</a> or <a href="index.html#zip">Zip</a> files for deployment, while
-the <a href="index.html#war">War</a> task extends the jar task for
+Ant can <a href="manual/CoreTasks/jar.html">Jar</a>, <a href=
"manual/CoreTasks/tar.html">
+Tar</a> or <a href="manual/CoreTasks/zip.html">Zip</a> files for deployment,
while
+the <a href="manual/CoreTasks/war.html">War</a> task extends the jar task for
better servlet deployment. <a href = "jlink.html" >Jlink</a> 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. <a href=
-"index.html#cab">Cab</a> can be used on Win32 boxes to build a cab file
+"manual/OptionalTasks/cab.html">Cab</a> can be used on Win32 boxes to build
a cab file
which is useful if you have to target IE deployment.
<p>
@@ -333,7 +333,7 @@
The <a href = "index.html#ftp">ftp</a> 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 <a href=
-"index.html#fixcrlf">FixCRLF task</a> is often a useful interim step if
+"manual/CoreTasks/fixcrlf.html">FixCRLF task</a> 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
@@ -341,7 +341,7 @@
<p>
-EJB deployment is aided by the <a href="ejb.html">ejb tasks</a>. At the
+EJB deployment is aided by the <a href="manual/OptionalTasks/ejb.html">ejb
tasks</a>. At the
time of writing, only WebLogic was supported with these tasks -if your
EJB server is not supported, extending the ejb tasks would benefit your
project and the rest of the ant community.
@@ -349,9 +349,9 @@
<p>
Finally, there are of course the fallbacks of just copying files to a
-destination using <a href="index.html#copy">Copy</a> and <a href =
+destination using <a href="manual/CoreTasks/copy.html">Copy</a> and <a href =
"index.html#copydir">Copydir</a> , or just sending them to a person or
-process using <a href= "index.html#mail">Mail</a>.
+process using <a href= "manual/CoreTasks/mail.html">Mail</a>.
<a name="directories">
<h2> Directory Structures</h2>
@@ -527,7 +527,7 @@
get
</b><dd>
-The <a href="index.html#get">get</a> task can fetch any URL, so be used
+The <a href="manual/CoreTasks/get.html">get</a> 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
@@ -538,7 +538,7 @@
Internationalisation is always trouble. Ant helps here with the <A href=
-"native2ascii.html">native2ascii</a> task which can escape out all non
+"manual/OptionalTasks/native2ascii.html">native2ascii</a> 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
language and then use native2ascii to convert to ascii prior to feeding
@@ -604,7 +604,7 @@
</b><dd>
XSLT can be used to dynamically generate build.xml files from a source
-xml file, with the <a href="index.html#style">Style</a> task controlling
+xml file, with the <a href="manual/CoreTasks/style.html">Style</a> task
controlling
the transform. This is the current recommended strategy for creating
complex build files dynamically.
