Return-Path: Delivered-To: apmail-ant-user-archive@ant.apache.org Received: (qmail 85257 invoked by uid 500); 6 Aug 2003 12:38:33 -0000 Mailing-List: contact user-help@ant.apache.org; run by ezmlm Precedence: bulk List-Unsubscribe: List-Subscribe: List-Help: List-Post: List-Id: "Ant Users List" Reply-To: "Ant Users List" Delivered-To: mailing list user@ant.apache.org Received: (qmail 85246 invoked from network); 6 Aug 2003 12:38:33 -0000 Received: from mailhost.cs.man.ac.uk (130.88.192.14) by daedalus.apache.org with SMTP; 6 Aug 2003 12:38:33 -0000 Received: from rpc71 ([130.88.198.228] helo=rpc71.cs.man.ac.uk) by mailhost with esmtp (Exim 4.14) id 19kNYe-0000xn-H8 for user@ant.apache.org; Wed, 06 Aug 2003 13:38:24 +0100 Received: (from phillord@localhost) by rpc71.cs.man.ac.uk (8.11.6/8.9.3) id h76CcPt04784; Wed, 6 Aug 2003 13:38:25 +0100 X-Authentication-Warning: rpc71.cs.man.ac.uk: phillord set sender to p.lord@russet.org.uk using -f Sender: phillord@cs.man.ac.uk To: "Ant Users List" Subject: Re: antmerge:- inheriting ant files. References: <36E996B162DAD111B6AF0000F879AD1AB81DD3@nts_par1.paranor.ch> From: Phillip Lord In-Reply-To: <36E996B162DAD111B6AF0000F879AD1AB81DD3@nts_par1.paranor.ch> Date: 06 Aug 2003 13:38:25 +0100 Message-ID: Lines: 59 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2.93 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: -6.5 (------) X-Scanner: exiscan for exim4 (http://duncanthrax.net/exiscan/) *19kNYe-0000xn-H8*fQumRqaOeYc* X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N >>>>> "Knut" == Wannheden, Knut writes: Knut> Looks great! Knut> Very similar to what I've done for our development environment Knut> with a few minor differences: I figured someone must have done something similar, but I couldn't find anything on the web before I wrote this. Writing build utilities is not really what I am paid for! Knut> o I have explicit top-level elements called , Knut> , and Knut> o In the metioned top-level elements a child element Knut> will be Knut> replaced with the respective contents of the parent buildfile Knut> o Attributes of the top-level elements are also inherited Knut> unless explicitly Knut> overridden (e.g. ) Knut> I don't know whether this makes any sense in your environment, Knut> but I certainly found this to be a very flexible templating Knut> mechanism. I have certainly thought about something similar, although I have not got around to implementing it yet. I don't particularly want to use explicit top level elements (as I want people to be able to use ant support from their IDE...so I use a DTD aware editor, and using the standard ant DTD is therefore a good thing!), but the lack of a "super" type functionality is a problem. Knut> Although it is a little bit disturbing that editing the Knut> "build-in.xml" is pretty challenging, as you have to visualize Knut> the eventually generated buildfile in your mind. Antmerge has a standard set of rules for generating the build file which generally "do the right thing". There are cases where they do not. Most of these are due to ordering of the end build file. Its a little hard to explain, so just trust me. I think I can get around it with some sorting of the end build.xml file based on top level tag. So all the "property" tags will come first, then all the path like structures next, and finally all the targets. How well this will work in practice, I don't know. Sometimes these heuristics sound great, and work badly. And sometimes the opposite. It's interesting actually. I notice that ant may be getting an "import" task (its in the CVS). I think that they will have some of the same problems as me. Parts of ant are procedural (properties, paths), and parts are not (targets). Import is fine. But where do you import? Phil --------------------------------------------------------------------- To unsubscribe, e-mail: user-unsubscribe@ant.apache.org For additional commands, e-mail: user-help@ant.apache.org