Return-Path: 
 <dev-return-48912-apmail-ant-dev-archive=ant.apache.org@ant.apache.org>
Delivered-To: apmail-ant-dev-archive@ant.apache.org
Received: (qmail 91098 invoked by uid 500); 31 Jul 2003 12:28:54 -0000
Mailing-List: contact dev-help@ant.apache.org; run by ezmlm
Precedence: bulk
List-Unsubscribe: <mailto:dev-unsubscribe@ant.apache.org>
List-Subscribe: <mailto:dev-subscribe@ant.apache.org>
List-Help: <mailto:dev-help@ant.apache.org>
List-Post: <mailto:dev@ant.apache.org>
List-Id: "Ant Developers List" <dev.ant.apache.org>
Reply-To: "Ant Developers List" <dev@ant.apache.org>
Delivered-To: mailing list dev@ant.apache.org
Received: (qmail 91066 invoked from network); 31 Jul 2003 12:28:53 -0000
Received: from mail.paranor.ch (HELO nts?par1.paranor.ch) (195.65.4.180)
  by daedalus.apache.org with SMTP; 31 Jul 2003 12:28:53 -0000
Received: by nts_par1.paranor.ch with Internet Mail Service (5.5.2448.0)
	id <3SL6C2JH>; Thu, 31 Jul 2003 14:28:49 +0200
Message-ID: <36E996B162DAD111B6AF0000F879AD1A76C336@nts_par1.paranor.ch>
From: "Wannheden, Knut" <knut.wannheden@paranor.ch>
To: 'Ant Developers List' <dev@ant.apache.org>
Subject: RE: override
Date: Thu, 31 Jul 2003 14:28:49 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C3575F.4B63BF66"
X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N

------_=_NextPart_001_01C3575F.4B63BF66
Content-Type: text/plain;
	charset="iso-8859-1"

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

------_=_NextPart_001_01C3575F.4B63BF66--