ant-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Paul Christmann" <>
Subject modified xmlproperty
Date Fri, 04 Oct 2002 20:07:50 GMT
I've written a modified version of the XmlProperty task with the
following additional behavior:

+ support for some "semantic" attributes: location, refid, id attributes
can be used in the XML file, with roughly the same meaning as with
<property> tasks in a build file.
+ support for ${..} dereferencing of attribute values.
+ support for specifying paths.

These enhancements have enabled us to move *all* of our configuration
data out of the build file into a separate valid xml file that can be
shared across an assortment of subprojects.  Its sort-of like the
approach advocated in section 9.4 of JDA, but with two important
+ The property file is itself a valid xml doc, rather than an xml
+ Resolution of location-type properties can be controlled in the
buildfile (via an attribute of the xmlproperty task) to either the
location of the properties file or the location of the original build
file (or any other location, if desired).

This version of the XmlProperty task supports the following additional
+ semanticAttributes: defaults to false; set it to true to turn on any
of this behavior.  With it false, it acts exactly like existing
XmlProperty task
+ rootDirectory: the location to use for resolving file references in
the properties file.  Defaults to ${basedir}.
+ includeSemanticAttribute: Whether or not to include the semantic
attribute itself in the property name.  Defaults to false.

So, my property file looks something like this:

  <project version="0.99"/>

    <dir location="build"/>
    <classes location="${build.dir}/classes"/>

  <classpath pathid="build.classpath">
    <pathelement location="${lib.dir}/*.jar"/>
  <classpath pathid="build.classpath">
    <path refid="build.classpath"/>
    <pathelement location="${build.classes}"/>

Loading this is equivalent to the following in my build file:

<property name="project.version" value="0.99"/>
<property name="build.dir" location="build"/>
<property name="build.classes" location="${build.dir}/classes"/>

<path id="build.classpath">
  <pathelement location="${lib.dir}/*.jar"/>

<path id="run.classpath">
  <path refid="build.classpath"/>
  <pathelement location="${build.classes}"/>

Would anyone else be interested in this task?  I'd gladly contribute it
to either jakarta or any one who would be interested.  

I should also note the minor annoyance with use of this task: Whereas
<property> elements can be specified at the root level of a build file,
<xmlproperty> cannot.  So I've had to define a task that loads the
properties, and make sure that is added to the dependency list in front
of *all* my tasks.  This wasn't that big of an issue, since most of my
tasks had a dependency on "init" anyway.  However, the value we're
getting from full sharing of properties across our builds more than
offsets this.

Paul C.
Paul Christmann
Prior Artisans

To unsubscribe, e-mail:   <>
For additional commands, e-mail: <>

View raw message