ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Wannheden, Knut" <>
Subject RE: override
Date Thu, 31 Jul 2003 12:28:49 GMT
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:

 <override-target name="compile">

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/>.


> 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=""/>
>   <taskdef name="super" 
> classname="$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>

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