You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ant.apache.org by eh...@apache.org on 2003/02/16 03:15:18 UTC
cvs commit: ant/proposal/xdocs/src/org/apache/tools/ant/taskdefs ConditionTask.xml Javac.xml Javadoc.xml Tar.xml
ehatcher 2003/02/15 18:15:18
Added: proposal/xdocs/src/org/apache/tools/ant/taskdefs
ConditionTask.xml Javac.xml Javadoc.xml Tar.xml
Log:
changing filename case
Revision Changes Path
1.1 ant/proposal/xdocs/src/org/apache/tools/ant/taskdefs/ConditionTask.xml
Index: ConditionTask.xml
===================================================================
<!-- Condition task -->
<external>
<description>
<p>Sets a property if a certain condition holds true - this is a
generalization of <a href="available.html">Available</a> and <a
href="uptodate.html">Uptodate</a>.</p>
<p>If the condition holds true, the property value is set to true by
default; otherwise, the property is not set. You can set the value to
something other than the default by specifying the <code>value</code>
attribute.</p>
<p>Conditions are specified as <a href="#nested">nested elements</a>,
you must specify exactly one condition.</p>
</description>
<section anchor="examples" name="Examples">
<pre>
<condition property="javamail.complete">
<and>
<available classname="javax.activation.DataHandler" />
<available classname="javax.mail.Transport" />
</and>
</condition>
</pre>
<p>sets the property <code>javamail.complete</code> if both the
JavaBeans Activation Framework and JavaMail are available in the
classpath.</p>
<pre>
<condition property="isMacOsButNotMacOsX">
<and>
<os family="mac" />
<not>
<os family="unix" />
</not>
</and>
</condition>
</pre>
<p>sets the property <code>isMacOsButNotMacOsX</code> if the current
operating system is MacOS, but not MacOS X - which Ant considers to be
in the Unix family as well.</p>
<pre>
<condition property="isSunOSonSparc">
<os name="SunOS" arch="sparc" />
</condition>
</pre>
<p>sets the property <code>isSunOSonSparc</code> if the current
operating system is SunOS and if it is running on a sparc architecture.</p>
</section>
</external>
1.1 ant/proposal/xdocs/src/org/apache/tools/ant/taskdefs/Javac.xml
Index: Javac.xml
===================================================================
<!-- javac task -->
<external>
<description>
<p>Compiles a Java source tree.</p>
<p>The source and destination directory will be recursively scanned for Java
source files to compile. Only Java files that have no corresponding class file
or where the class file is older than the java file will be compiled.</p>
<p>Note: Ant uses only the names of the source and class files to find
the classes that need a rebuild. It will not scan the source and therefor
will have no knowledge about nested classes, classes that are named different
from the source file and so on.</p>
<p>The directory structure of the source tree should follow the package
hierarchy.</p>
<p>It is possible to refine the set of files that are being compiled/copied.
This can be done with the <i>includes</i>, <i>includesfile</i>, <i>excludes</i>, <i>excludesfile</i> and <i>defaultexcludes</i>
attributes. With the <i>includes</i> or <i>includesfile</i> attribute you specify the files you want to
have included by using patterns. The <i>exclude</i> or <i>excludesfile</i> attribute is used to specify
the files you want to have excluded. This is also done with patterns. And
finally with the <i>defaultexcludes</i> attribute, you can specify whether you
want to use default exclusions or not. See the section on <a
href="../dirtasks.html#directorybasedtasks">directory based tasks</a>, on how the
inclusion/exclusion of files works, and how to write patterns.</p>
<p>It is possible to use different compilers. This can be selected with the
"build.compiler" property or the compiler attribute. Here are the choices:-</p>
<ul>
<li>classic (the standard compiler of JDK 1.1/1.2) - javac1.1 and
javac1.2 can be used as aliases</li>
<li>modern (the standard compiler of JDK 1.3/1.4) - javac1.3 and
javac1.4 can be used as aliases</li>
<li>jikes (the <a
href="http://oss.software.ibm.com/developerworks/opensource/jikes/project" target="_top">Jikes</a>
compiler)</li>
<li>jvc (the Command-Line Compiler from Microsoft's SDK for Java /
Visual J++) - microsoft can be used as an alias</li>
<li>kjc (the <a href="http://www.dms.at/kopi/" target="_top">kopi</a>
compiler)</li>
<li>gcj (the gcj compiler from gcc)</li>
<li>sj (Symantec java compiler) - symantec can be used as an alias</li>
<li>extJavac (run either modern or classic in a JVM of its own)</li>
</ul>
<p>For JDK 1.1/1.2, classic is the default. For JDK 1.3/1.4, modern is the default.
If you wish to use a different compiler interface than those
supplied, write a class that implements the CompilerAdapter interface
(package org.apache.tools.ant.taskdefs.compilers). Supply the full
classname in the "build.compiler" property.</p>
<p>The fork attribute overrides the build.compiler setting and expects
a JDK1.1 or higher to be set in java.home.</p>
<p>This task will drop all entries that point to non-existent
files/directories from the CLASSPATH it passes to the compiler.</p>
<p><strong>Windows Note:</strong>When the modern compiler is used
in unforked mode on Windows, it locks up the files present in the
classpath of the <javac> task, and does not release them. The side
effect of this is that you will not be able to delete or move
those files later on in the build. The workaround is to fork when
invoking the compiler.</p>
</description>
<section anchor="examples" name="Examples">
<pre> <javac srcdir="${src}"
destdir="${build}"
classpath="xyz.jar"
debug="on"
/></pre>
<p>compiles all <code>.java</code> files under the <code>${src}</code>
directory, and stores
the <code>.class</code> files in the <code>${build}</code> directory.
The classpath used contains <code>xyz.jar</code>, and debug information is on.</p>
<pre> <javac srcdir="${src}"
destdir="${build}"
fork="true"
/></pre>
<p>compiles all <code>.java</code> files under the <code>${src}</code>
directory, and stores the <code>.class</code> files in the
<code>${build}</code> directory. This will fork off the javac
compiler using the default javac executable.</p>
<pre> <javac srcdir="${src}"
destdir="${build}"
fork="java$$javac.exe"
/></pre>
<p>compiles all <code>.java</code> files under the <code>${src}</code>
directory, and stores the <code>.class</code> files in the
<code>${build}</code> directory. This will fork off the javac
compiler using the executable named <code>java$javac.exe</code>. Note
that the <code>$</code> sign needs to be escaped by a second one.</p>
<pre> <javac srcdir="${src}"
destdir="${build}"
includes="mypackage/p1/**,mypackage/p2/**"
excludes="mypackage/p1/testpackage/**"
classpath="xyz.jar"
debug="on"
/></pre>
<p>compiles <code>.java</code> files under the <code>${src}</code>
directory, and stores the
<code>.class</code> files in the <code>${build}</code> directory.
The classpath used contains <code>xyz.jar</code>, and debug information is on.
Only files under <code>mypackage/p1</code> and <code>mypackage/p2</code> are
used. Files in the <code>mypackage/p1/testpackage</code> directory are excluded
from compilation.</p>
<pre> <javac srcdir="${src}:${src2}"
destdir="${build}"
includes="mypackage/p1/**,mypackage/p2/**"
excludes="mypackage/p1/testpackage/**"
classpath="xyz.jar"
debug="on"
/></pre>
<p>is the same as the previous example, with the addition of a second
source path, defined by
the property <code>src2</code>. This can also be represented using nested
<code><src></code> elements as follows:</p>
<pre> <javac destdir="${build}"
classpath="xyz.jar"
debug="on">
<src path="${src}"/>
<src path="${src2}"/>
<include name="mypackage/p1/**"/>
<include name="mypackage/p2/**"/>
<exclude name="mypackage/p1/testpackage/**"/>
</javac></pre>
<p><b>Note:</b> If you are using Ant on Windows and a new DOS window pops up
for every use of an external compiler, this may be a problem of the JDK you are using.
This problem may occur with all JDKs < 1.2.</p>
<p><b>Note:</b> If you wish to compile only source-files located in some packages below a
common root you should not include these packages in the srcdir-attribute. Use include/exclude-attributes
or elements to filter for these packages. If you include part of your package-structure inside the srcdir-attribute
(or nested src-elements) Ant will start to recompile your sources every time you call it.</p>
</section>
<section anchor="jikes" name="Jikes Notes">
<p>Jikes supports some extra options, which can be set be defining
properties prior to invoking the task. The ant developers are aware that
this is ugly and inflexible -expect a better solution in the future. All
the options are boolean, and must be set to "true" or "yes" to be
interpreted as anything other than false; by default
build.compiler.warnings is "true" while all others are "false"</p>
<table border="1" cellpadding="2" cellspacing="0">
<tr>
<td valign="top">
build.compiler.emacs
</td>
<td valign="top">
Enable emacs compatible error messages
</td>
</tr>
<tr>
<td valign="top">
build.compiler.warnings<br />
<b>This property has been deprecated, use the nowarn attribute
instead</b>
</td>
<td valign="top">
don't disable warning messages
</td>
</tr>
<tr>
<td valign="top">
build.compiler.pedantic
</td>
<td valign="top">
enable pedantic warnings
</td>
</tr>
<tr>
<td valign="top">
build.compiler.fulldepend
</td>
<td valign="top">
enable full dependency checking,<br />
"+F" in the jikes manual.
</td>
</tr>
</table>
</section>
</external>
1.1 ant/proposal/xdocs/src/org/apache/tools/ant/taskdefs/Javadoc.xml
Index: Javadoc.xml
===================================================================
<!-- javadoc task -->
<external>
<description>
<p>Generates code documentation using the javadoc tool.</p>
<p>The source directory will be recursively scanned for Java source files to process
but only those matching the inclusion rules, and not matching the exclusions rules
will be passed to the javadoc tool. This
allows wildcards to be used to choose between package names, reducing verbosity
and management costs over time. This task, however, has no notion of
"changed" files, unlike the <a href="javac.html">javac</a> task. This means
all packages will be processed each time this task is run. In general, however,
this task is used much less frequently.</p>
<p>This task works seamlessly between different javadoc versions (1.1 and 1.2),
with the obvious restriction that the 1.2 attributes will be ignored if run in a
1.1 VM.</p>
<p>NOTE: since javadoc calls System.exit(), javadoc cannot be run inside the
same VM as ant without breaking functionality. For this reason, this task
always forks the VM. This overhead is not significant since javadoc is normally a heavy
application and will be called infrequently.</p>
<p>NOTE: the packagelist attribute allows you to specify the list of packages to
document outside of the Ant file. It's a much better practice to include everything
inside the build.xml file. This option was added in order to make it easier to
migrate from regular makefiles, where you would use this option of javadoc.
The packages listed in packagelist are not checked, so the task performs even
if some packages are missing or broken. Use this option if you wish to convert from
an existing makefile. Once things are running you should then switch to the regular
notation. </p>
<p><i><b>DEPRECATION:</b> the javadoc2 task simply points to the javadoc task and it's
there for back compatibility reasons. Since this task will be removed in future
versions, you are strongly encouraged to use <a href="javadoc.html">javadoc</a>
instead.</i></p>
</description>
<section anchor="examples" name="Example">
<pre> <javadoc packagenames="com.dummy.test.*"
sourcepath="src"
excludepackagenames="com.dummy.test.doc-files.*"
defaultexcludes="yes"
destdir="docs/api"
author="true"
version="true"
use="true"
windowtitle="Test API">
<doctitle><![CDATA[<h1>Test</h1>]]></doctitle>
<bottom><![CDATA[<i>Copyright &#169; 2000 Dummy Corp. All Rights Reserved.</i>]]></bottom>
<tag name="todo" scope="all" description="To do:" />
<group title="Group 1 Packages" packages="com.dummy.test.a*"/>
<group title="Group 2 Packages" packages="com.dummy.test.b*:com.dummy.test.c*"/>
<link offline="true" href="http://java.sun.com/products/jdk/1.2/docs/api/" packagelistLoc="C:\tmp"/>
<link href="http://developer.java.sun.com/developer/products/xml/docs/api/"/>
</javadoc></pre>
</section>
</external>
1.1 ant/proposal/xdocs/src/org/apache/tools/ant/taskdefs/Tar.xml
Index: Tar.xml
===================================================================
<!-- tar task -->
<external>
<description>
<p>Creates a tar archive.</p>
<p>The <i>basedir</i> attribute is the reference directory from where to tar.</p>
<p>This task is a <a href="../dirtasks.html#directorybasedtasks">directory based task</a>
and, as such, forms an implicit <a href="../CoreTypes/fileset.html">Fileset</a>. This
defines which files, relative to the <i>basedir</i>, will be included in the
archive. The tar task supports all the attributes of Fileset to refine the
set of files to be included in the implicit fileset.</p>
<p>In addition to the implicit fileset, the tar task supports nested filesets. These
filesets are extended to allow control over the access mode, username and groupname
to be applied to the tar entries. This is useful, for example, when preparing archives for
Unix systems where some files need to have execute permission.</p>
<p>Early versions of tar did not support path lengths greater than 100
characters. Modern versions of tar do so, but in incompatible ways.
The behaviour of the tar task when it encounters such paths is
controlled by the <i>longfile</i> attribute.
If the longfile attribute is set to <code>fail</code>, any long paths will
cause the tar task to fail. If the longfile attribute is set to
<code>truncate</code>, any long paths will be truncated to the 100 character
maximum length prior to adding to the archive. If the value of the longfile
attribute is set to <code>omit</code> then files containing long paths will be
omitted from the archive. Either option ensures that the archive can be
untarred by any compliant version of tar. If the loss of path or file
information is not acceptable, and it rarely is, longfile may be set to the
value <code>gnu</code>. The tar task will then produce a GNU tar file which
can have arbitrary length paths. Note however, that the resulting archive will
only be able to be untarred with GNU tar. The default for the longfile
attribute is <code>warn</code> which behaves just like the gnu option except
that it produces a warning for each file path encountered that does not match
the limit.</p>
<p>Note that this task does not perform compression. You might want to use the
<a href="gzip.html">GZip</a> task to prepare a .tar.gz package.</p>
</description>
<section anchor="examples" name="Examples">
<pre> <tar tarfile="${dist}/manual.tar" basedir="htdocs/manual"/>
<gzip zipfile="${dist}/manual.tar.gz" src="${dist}/manual.tar"/></pre>
<p>tars all files in the <code>htdocs/manual</code> directory into a file called <code>manual.tar</code>
in the <code>${dist}</code> directory, then applies the gzip task to compress
it.</p>
<pre> <tar destfile="${dist}/manual.tar"
basedir="htdocs/manual"
excludes="mydocs/**, **/todo.html"
/></pre>
<p>tars all files in the <code>htdocs/manual</code> directory into a file called <code>manual.tar</code>
in the <code>${dist}</code> directory. Files in the directory <code>mydocs</code>,
or files with the name <code>todo.html</code> are excluded.</p>
<pre>
<tar destfile="${basedir}/docs.tar">
<tarfileset dir="${dir.src}/docs"
fullpath="/usr/doc/ant/README"
preserveLeadingSlashes="true">
<include name="readme.txt"/>
</tarfileset>
<tarfileset dir="${dir.src}/docs"
prefix="/usr/doc/ant"
preserveLeadingSlashes="true">
<include name="*.html"/>
</tarfileset>
</tar></pre>
<p>
Writes the file <code>docs/readme.txt</code> as
<code>/usr/doc/ant/README</code> into the archive. All
<code>*.html</code> files in the <code>docs</code> directory are
prefixed by <code>/usr/doc/ant</code>, so for example
<code>docs/index.html</code> is written as
<code>/usr/doc/ant/index.html</code> to the archive.
</p>
<pre><tar longfile="gnu"
destfile="${dist.base}/${dist.name}-src.tar" >
<tarfileset dir="${dist.name}/.." mode="755" username="ant" group="ant">
<include name="${dist.name}/bootstrap.sh"/>
<include name="${dist.name}/build.sh"/>
</tarfileset>
<tarfileset dir="${dist.name}/.." username="ant" group="ant">
<include name="${dist.name}/**"/>
<exclude name="${dist.name}/bootstrap.sh"/>
<exclude name="${dist.name}/build.sh"/>
</tarfileset>
</tar> </pre>
<p>This example shows building a tar which uses the GNU extensions for long paths and
where some files need to be marked as executable (mode 755)
and the rest are use the default mode (read-write by owner). The first
fileset selects just the executable files. The second fileset must exclude
the executable files and include all others. </p>
<p><strong>Note: </strong> The tar task does not ensure that a file is only selected
by one fileset. If the same file is selected by more than one fileset, it will be included in the
tar file twice, with the same path.</p>
<p><strong>Note:</strong> The patterns in the include and exclude
elements are considered to be relative to the corresponding dir
attribute as with all other filesets. In the example above,
<code>${dist.name}</code> is not an absolute path, but a simple name
of a directory, so <code>${dist.name}</code> is a valid path relative
to <code>${dist.name}/..</code>.</p>
</section>
</external>