ant-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jacob Kjome <>
Subject Re: modified xmlproperty
Date Sun, 06 Oct 2002 01:55:55 GMT
This sounds really useful!

Please provide a location to download it or attach it to the 
list.  Probably want to add a small build file + external properties file 
showing usage.


At 03:07 PM 10/4/2002 -0500, you wrote:
>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"/>
>   <build>
>     <dir location="build"/>
>     <classes location="${build.dir}/classes"/>
>   </build>
>   <classpath pathid="build.classpath">
>     <pathelement location="${lib.dir}/*.jar"/>
>   </classpath>
>   <classpath pathid="build.classpath">
>     <path refid="build.classpath"/>
>     <pathelement location="${build.classes}"/>
>   </classpath>
>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: <>

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message