<?xml version="1.0" encoding="UTF-8" ?> <project name="testsite" basedir="." default="main"> <property file="./build.properties" /> <property name="package" value="${phing.project.name}" override="true" /> <property name="builddir" value="./build/testsite" override="true" /> <property name="srcdir" value="${project.basedir}" override="true" /> <!-- Fileset for all files --> <fileset dir="." id="allfiles"> <include name="**" /> </fileset> <!-- ============================================ --> <!-- (DEFAULT) Target: main --> <!-- ============================================ --> <target name="main" description="main target"> <copy todir="${builddir}"> <fileset refid="allfiles" /> </copy> </target> <!-- ============================================ --> <!-- Target: Rebuild --> <!-- ============================================ --> <target name="rebuild" description="rebuilds this package"> <delete dir="${builddir}" /> <phingcall target="main" /> </target> </project>
This build file first defines some properties with the
<property>
task call to PropertyTask
. Then,
it defines a fileset and two targets.
Let us have a quick rundown of this build file.
The first four tags within the project
tag define properties. They
appear in two possible variants:
The first property
tag contains only the
file
attribute. The value has to be a relative or
absolute path to a property file (for the format, see Appendix J, File Formats).
The other times, the tag has a name
and a
value
attribute. After the call, the value defined in the
attribute value
is available through the key enclosed in
"${" and "}".
The next noticeable thing in the build file is the <fileset>
tag. It defines a fileset
, i.e. a set of multiple files. You can
include and exclude files with the include
and
exclude
tags within the fileset
tag. For more
information concerning Filesets (i.e. Patterns) see Appendix D, Core Types.
The fileset
is given an id
attribute, so it can be
referenced later on.
One thing is worth noting here though and that is the use of double star expression,
i.e. "**"
. This special regexp refers to all files in all
subdirectories as well. Compare this with a single "*"
which would
only refer to all files in the current
subdirectory. So for example
the expression "**/*.phps"
would refer to all files with suffix
"'.phps"
in all subdirectories below the current directory.
The first task only contains a call to CopyTask
via
<copy>
. The interesting thing is within the
copy
tag. Here, a fileset task is not written out with nested
include
or exclude
elements, but via the
refid
, the Fileset created earlier is referenced. This way, you
can use a once defined fileset multiple times in your build files.
The only noticeable thing in the second target is the call to
PhingTask
with the <phingcall>
tag (see
Appendix B, Core tasks for more information). The task executes a
specified target within the same build file. So, the second target removes the build
directory and calls main
again, thus rebuilding the project.
A variant is to override properties defined in the build file with properties
specified on the command line using the -D
switch. For example to
override the builddir
in the build file above one could call Phing
as
$ phing -Dbuilddir=/tmp/system-test
A common task required in many build files is to keep some target which has a
number of dependencies up to date. In traditional make files this could for example
be an executable that needs to be recompiled if any of the source files have been
updated. In Phing such a condition is handled by the UpToDateTask
, see Section B.69, “UpToDateTask” for examples on how this task us
used.