ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jose Alberto Fernandez <JFernan...@viquity.com>
Subject RE: XSLT (was Re: Immutable Properties in 1.1?)
Date Sat, 22 Jul 2000 02:38:20 GMT
One could used in-lined Stylesheets.The styleshet embeded in the
ANT file. Xalan knows how to deal with this kind of thing.
We would just need an option on ANT indicating the file should be passed
thru Xalan and listen to the event produced by Xalan instead of the parser.

No need for two passes with that....

Jose Alberto


> -----Original Message-----
> From: Roger Vaughn [mailto:rvaughn@seaconinc.com]
> Sent: Friday, July 21, 2000 5:47 PM
> To: ant-dev@jakarta.apache.org
> Subject: Re: XSLT (was Re: Immutable Properties in 1.1?)
> 
> 
> mpfoemme@ThoughtWorks.com 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>
> 
> <target name="jar2">
>   <property name="jarfile" value="jar2.jar"/>
>   <property name="includes" value="**/someotherfiles"/>
>   <!-- some code that uses ${jarfile} and ${includes} -->
> </target>
> 
> now becomes:
> 
> <xsl:template match="myjar">
>   <!-- some code that uses "{@jarfile}" and 
> <xsl:apply-templates select="include|exclude"/>
> -->
> </xsl:template>
> 
> <target name="jar1">
>   <myjar jarfile="jar1.jar">
>     <include name="**/somefiles"/>
>   </myjar>
> </target>
> 
> <target name="jar2">
>   <myjar jarfile="jar2.jar">
>     <include name="**/someotherfiles"/>
>   </myjar>
> </target>
> 
> 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.
> 
> roger
> 
> 

Mime
View raw message