ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dominique Devienne <DDevie...@lgc.com>
Subject RE: override
Date Thu, 31 Jul 2003 14:25:12 GMT
Indeed ;-) What you demoed Conor is precisely the use case I need, which was
very much inspired by Knut's past posts. I also like Knut's
<override-target> name better, as it's more explicit.

The one thing I'm not too sure about is the <override-property> and
<override-path> ones... Why are these needed? Property immutability is one
tenet of Ant we shouldn't lightly consider.

<override-reference> might be useful, but even then I'm not sure now that we
have <isreference>, i.e. now that we have the ability to check before a
target's execution that it data it needs is there or not. E.g.:

<target name="copy-resources"
        depends="-has-resources?"
        if="-has-resources">
  <copy> 
    <fileset refid="resources" />
  </copy>
</target>

<target name="-has-resources?">
  <condition property="-has-resources"> 
    <isreference refid="resources" type="fileset" />
  </condition>
</target>

--DD

PS: I checked the online manual, and didn't see <isreference>. After the
discussion I had with Stefan, I thought it was there... Did I misunderstand,
or is it just not documented.

> -----Original Message-----
> From: Wannheden, Knut [mailto:knut.wannheden@paranor.ch]
> Sent: Thursday, July 31, 2003 7:29 AM
> To: 'Ant Developers List'
> Subject: RE: override
> 
> This very much reminds me of what I was doing in our build environment.  I
> basically had a template buildfile and could override that for any project
> like this:
> 
> <project>
>  <override-target name="compile">
>   <.../>
>   <super/>
>   <.../>
>  </override-target>
> </project>
> 
> The difference is only that I didn't implement <override-target/> as a
> task
> (top-level tasks didn't exist back then).  (Similarly with
> <override-property/> and <override-path/>.)  Instead I generated a new
> buildfile with XSLT (later with dom4j).
> 
> The problem I had was that it was hard to control where to place the
> top-level tasks in the generated buildfile.  But this looks like it would
> be
> simpler with a renaming <import/>.
> 
> --
> knut
> 
> >
> > I'd like to take a slightly different angle on the <import>
> > issue by getting
> > some thoughts on this little experimental task I wrote. I
> > haven't cleaned it
> > up at all (lots of unused imports, inner classes etc). Anyway
> > it lets you
> > override any target in the build. e.g. This build file
> >
> > <project name="override" default="test">
> >
> >   <taskdef name="override"
> > classname="org.apache.tools.ant.taskdefs.Override"/>
> >   <taskdef name="super"
> > classname="org.apache.tools.ant.taskdefs.Override$Super"/>
> >
> >   <override target="test">
> >     <echo message="pre"/>
> >     <super/>
> >     <echo message="post"/>
> >   </override>
> >
> >   <override target="test">
> >     <echo message="pre2"/>
> >     <super/>
> >     <echo message="post2"/>
> >   </override>
> >
> >   <target name="test">
> >     <echo message="test"/>
> >   </target>
> >
> > </project>
> >

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org


Mime
View raw message