Return-Path: Delivered-To: apmail-ant-dev-archive@www.apache.org Received: (qmail 60233 invoked from network); 1 Sep 2003 14:14:16 -0000 Received: from daedalus.apache.org (HELO apache.org) (208.185.179.12) by minotaur-2.apache.org with SMTP; 1 Sep 2003 14:14:16 -0000 Received: (qmail 70510 invoked by uid 500); 1 Sep 2003 14:14:06 -0000 Delivered-To: apmail-ant-dev-archive@ant.apache.org Received: (qmail 70458 invoked by uid 500); 1 Sep 2003 14:14:05 -0000 Mailing-List: contact dev-help@ant.apache.org; run by ezmlm Precedence: bulk List-Unsubscribe: List-Subscribe: List-Help: List-Post: List-Id: "Ant Developers List" Reply-To: "Ant Developers List" Delivered-To: mailing list dev@ant.apache.org Received: (qmail 70438 invoked from network); 1 Sep 2003 14:14:04 -0000 Received: from unknown (HELO corvil.com) (213.94.219.177) by daedalus.apache.org with SMTP; 1 Sep 2003 14:14:04 -0000 Received: from preilly.local.corvil.com (preilly.local.corvil.com [172.18.1.173]) by corvil.com (8.12.9/8.12.5) with ESMTP id h81EDtxe044701 for ; Mon, 1 Sep 2003 15:13:55 +0100 (IST) (envelope-from peter.reilly@corvil.com) From: peter reilly Organization: corvil To: Ant Developers List Subject: Re: Getting 1.6 out the door Date: Mon, 1 Sep 2003 15:22:19 +0100 User-Agent: KMail/1.5 References: <200308282307.09555.conor@cortexebusiness.com.au> In-Reply-To: <200308282307.09555.conor@cortexebusiness.com.au> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200309011522.20034.peter.reilly@corvil.com> X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N X-Spam-Rating: minotaur-2.apache.org 1.6.2 0/1000/N Hi, I was on holidays the last two weeks and so will use this reply to some of the issues. On Thursday 28 August 2003 14:07, Conor MacNeill wrote: > My position on these issues is > > 1. > > Go with it as is. I think it is useful and useable without coming up > against some of the cases we have discussed. How we address those issues > can be tackled later, perhaps with a different mechanism. That is bound up > in the whole issue of target visibility and overriding. +1 to use as is. > > I'm not sure whether we should provide a simple as well which > does no renaming (overrides)? > > 2. antlib > > I think this should be in but I am not familiar with its state yet, nor do > I think it has had enough testing - might just be my own need to kick the > tyres. Are we planning to antlib Ant's own optional jars? In 1.7 I think we > need to look at removing antlibs from the root loader when their dependent > jars are not available in ANT_HOME/lib. + 1 for antlib in 1.6 , -1 to use for ant's optional jars in 1.6 +1 (from Dominique) to add antlib.xml to antcontrib I have written a manual page for antlib. There is more work required (for example how to write a task to fit correct into an antlib - uri and classloader handling), it also uses and as examples ;-). > > 3. and > > These seem to have some issues lately and I suggest we pull these into 1.7 I would like them in 1.6 (but I would say that...), in particular I would like to be present. As far as I can see there are two issues with , handling of properties and handling of attributes. a) resolution of properties The issue here is that properties get resolved when the macro is used and not when the macro is defined. I think that it would be difficult to resolve the properties correctly when the macro is defined. For example: ${my.property} If the property "my.property" is not defined at the time of definition and is defined when "echo.my.property" is used, the Echo#setText() would be given ${my.property} and would resolve it. Also how does know that ${my.property} should be expanded for as against for where is it (incorrectly) not. I think that the current implementation and behaviour is preferable. b) syntax of attributes The issue here is that the syntax for macro attributes is the same as properties (i.e. ${name}), and that people may be confused between them. Some of the proposed syntaxes are: i) $[name] (Conor) ii) (@name) (Dominique) iii) {@param name} (Dominique) iv) ${macroattr:name} (Jose) After using macrodef for a little while (well mostly in writing examples), I think that ${name} feels the best. In future I expect that there will be different scopes for variables/properties (perhaps only for ant-contrib/antelope/other and not in core ant), - task level variables, macro level variables and global variables (properties). It would be strange to have different syntax for each. However this (unlike a) is easy to code for :-), if ${name} syntax is not liked my other preference would be ${macroattr:name}. Other issues for 1.6: * Doc for new introspection methods (add(type)) * polymorphic attribute (ant-type) Doc for this, is it useful? * It would be nice to get the classloader task to work. * overwriting definitions. Currently one can overwrite a definition with only a warning. It may be usefull to make it more difficult to overwrite definitions (Costin) - for example for namespaced definitions. After struggling with make's CCFLAGS, I really like ant's lack of magic varibles, so means and not . (I realise that I have gave an example of this in a previous e-mail). Peter --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org For additional commands, e-mail: dev-help@ant.apache.org