ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Wannheden, Knut" <knut.wannhe...@paranor.ch>
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:

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

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