ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Roger Vaughn <>
Subject Re: XSLT (was Re: Immutable Properties in 1.1?)
Date Sat, 22 Jul 2000 00:47:28 GMT wrote:

> I still think that using XSLT as a sort of "preprocessor" is the best way
> to handle these kind of situations. You could define the structure of your
> project in an XML file, using as simple a syntax as possible, then use XSL
> to generate your Ant file. This keeps the Ant syntax small and clean, while
> leveraging an already defined standard to automate the repetitive stuff...
> Matt Foemmel
> ThoughtWorks, Inc.

Just as an experiment, I did this.  While it does require a two-pass build (Imake-like), it
worked out pretty well.  The trick is to define your XSLT templates at the task level, thus
preserving the full Ant experience.  This way, your "original" build file (which I called
"ibuild.xml" out of sheer bloody-mindedness) looks like normal Ant with a few new taskdefs
added.  What you end up with is effectively new taskdefs which resolve to multi-task
sequences.  Also, since XSLT gives you an include mechanism, this gives you a way to write
your "common" tasks (like clean) once, and include them from a common file.

To go back to my original example, this:

<target name="jar1">
  <property name="jarfile" value="jar1.jar"/>
  <property name="includes" value="**/somefiles"/>
  <!-- some code that uses ${jarfile} and ${includes} -->

<target name="jar2">
  <property name="jarfile" value="jar2.jar"/>
  <property name="includes" value="**/someotherfiles"/>
  <!-- some code that uses ${jarfile} and ${includes} -->

now becomes:

<xsl:template match="myjar">
  <!-- some code that uses "{@jarfile}" and <xsl:apply-templates select="include|exclude"/>

<target name="jar1">
  <myjar jarfile="jar1.jar">
    <include name="**/somefiles"/>

<target name="jar2">
  <myjar jarfile="jar2.jar">
    <include name="**/someotherfiles"/>

Thus this preserves the syntactic purity of Ant.  Note, however, that it's just as much work
for simple examples - it's only effective for complex code blocks or simple ones that change
frequently in many places.

Only one caveat I have discovered so far - if your templates contain Ant property expansions
(i.e. ${prop}), you have to write them like this: ${{prop}}, since the brace is a reserved
syntactic construct in XSLT.  I would consider property expansions in templates to be bad
form and easy to break - prefer attributes in the original file instead.


View raw message