|
|
|
@@ -21,9 +21,10 @@ |
|
|
|
<li>Conor MacNeill (<a href="mailto:conor@cortexebusiness.com.au">conor@cortexebusiness.com.au</a>)</li> |
|
|
|
<li>Stefano Mazzocchi (<a href="mailto:stefano@apache.org">stefano@apache.org</a>)</li> |
|
|
|
<li>Sam Ruby (<a href="mailto:rubys@us.ibm.com">rubys@us.ibm.com</a>)</li> |
|
|
|
<li>Dave Walend (<a href="mailto:dwalend@cs.tufts.edu">dwalend@cs.tufts.edu</a>)</li> |
|
|
|
</ul> |
|
|
|
|
|
|
|
<p>Version 1.2 - 2000/07/26</p> |
|
|
|
<p>Version 1.2 - 2000/07/27</p> |
|
|
|
|
|
|
|
<hr> |
|
|
|
<h2>Table of Contents</h2> |
|
|
|
@@ -350,53 +351,60 @@ task attributes. This is done by placing the property name between |
|
|
|
<p>If there is a property called "builddir" with the value |
|
|
|
"build", then this could be used in an attribute like this: "${builddir}/classes". |
|
|
|
This is resolved as "build/classes".</p> |
|
|
|
<h3>Token Filters</h3> |
|
|
|
<p>A project can have a set of tokens that might be automatically expanded if |
|
|
|
found when a file is copied, when the filtering-copy behavior is selected in the |
|
|
|
tasks that support this. These might be set in the buildfile |
|
|
|
by the <a href="#filter">filter task</a>. </p> |
|
|
|
<p>Since this can be a very harmful behavior, the tokens in the files <b>must</b> |
|
|
|
be of the form<i> @token@</i> where <i>token</i> is the token name that is set |
|
|
|
in the filter task. This token syntax matches the syntax of other build systems |
|
|
|
that perform such filtering and remains sufficiently orthogonal to most |
|
|
|
programming and scripting languages, as well with documentation systems.</p> |
|
|
|
<p>Note: in case a token with the format @token@ if found in a file but no |
|
|
|
filter is associated with that token, no changes take place. So, no escaping |
|
|
|
method is present, but as long as you choose appropriate names for your tokens, |
|
|
|
this should not cause problems.</p> |
|
|
|
<h3>Examples</h3> |
|
|
|
<h3>Example</h3> |
|
|
|
<blockquote> |
|
|
|
<pre><project name="foo" default="dist" basedir="."> |
|
|
|
<target name="init"> |
|
|
|
<tstamp/> |
|
|
|
<property name="build" value="build" /> |
|
|
|
<property name="dist" value="dist" /> |
|
|
|
<filter token="version" value="1.0.3" /> |
|
|
|
<filter token="year" value="2000" /> |
|
|
|
</target> |
|
|
|
<pre> |
|
|
|
<project name="MyProject" default="dist" basedir="."> |
|
|
|
|
|
|
|
<target name="prepare" depends="init"> |
|
|
|
<!-- set global properties for this build --> |
|
|
|
<property name="src" value="." /> |
|
|
|
<property name="build" value="build" /> |
|
|
|
<property name="dist" value="dist" /> |
|
|
|
|
|
|
|
<target name="prepare"> |
|
|
|
<!-- Create the time stamp --> |
|
|
|
<tstamp/> |
|
|
|
<!-- Create the build directory structure used by compile --> |
|
|
|
<mkdir dir="${build}" /> |
|
|
|
</target> |
|
|
|
|
|
|
|
<target name="compile" depends="prepare"> |
|
|
|
<javac srcdir="${src}" destdir="${build}" filtering="on"/> |
|
|
|
<!-- Compile the java code from ${src} into ${build} --> |
|
|
|
<javac srcdir="${src}" destdir="${build}" /> |
|
|
|
</target> |
|
|
|
|
|
|
|
<target name="dist" depends="compile"> |
|
|
|
<!-- Create the ${dist}/lib directory --> |
|
|
|
<mkdir dir="${dist}/lib" /> |
|
|
|
<jar jarfile="${dist}/lib/foo${DSTAMP}.jar" |
|
|
|
basedir="${build}" items="com"/> |
|
|
|
|
|
|
|
<!-- Put everything in ${build} into the MyProject-${DSTAMP}.jar file --> |
|
|
|
<jar jarfile="${dist}/lib/MyProject-${DSTAMP}.jar" basedir="${build}" /> |
|
|
|
</target> |
|
|
|
|
|
|
|
<target name="clean" depends="init"> |
|
|
|
<target name="clean"> |
|
|
|
<!-- Delete the ${build} and ${dist} directory trees --> |
|
|
|
<deltree dir="${build}" /> |
|
|
|
<deltree dir="${dist}" /> |
|
|
|
</target> |
|
|
|
</project> |
|
|
|
</pre> |
|
|
|
</pre> |
|
|
|
</blockquote> |
|
|
|
|
|
|
|
<h3>Token Filters</h3> |
|
|
|
<p>A project can have a set of tokens that might be automatically expanded if |
|
|
|
found when a file is copied, when the filtering-copy behavior is selected in the |
|
|
|
tasks that support this. These might be set in the buildfile |
|
|
|
by the <a href="#filter">filter task</a>. </p> |
|
|
|
<p>Since this can be a very harmful behavior, the tokens in the files <b>must</b> |
|
|
|
be of the form<i> @token@</i> where <i>token</i> is the token name that is set |
|
|
|
in the filter task. This token syntax matches the syntax of other build systems |
|
|
|
that perform such filtering and remains sufficiently orthogonal to most |
|
|
|
programming and scripting languages, as well with documentation systems.</p> |
|
|
|
<p>Note: in case a token with the format @token@ if found in a file but no |
|
|
|
filter is associated with that token, no changes take place. So, no escaping |
|
|
|
method is present, but as long as you choose appropriate names for your tokens, |
|
|
|
this should not cause problems.</p> |
|
|
|
|
|
|
|
<h3><a name="path">PATH like structures</a></h3> |
|
|
|
<p>You can specify PATH and CLASSPATH variables using both |
|
|
|
":" and ";" as separator characters, Ant will |
|
|
|
|
Conor MacNeill