Re: Getting 1.6 out the door

[peter reilly <pe...@corvil.com>]

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. <import>
>
> 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 <import> as is.
>
> I'm not sure whether we should provide a simple <include> 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 <macrodef> and <presetdef> as examples ;-).

>
> 3. <macrodef> and <presetdef>
>
> 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 <macrodef> to be present.

As far as I can see there are two issues with <macrodef>, 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:

     <macrodef name="echo.my.property">
        <sequential>
           <echo>${my.property}</echo>
        </sequential>
     <macrodef>

     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 <macrodef>
     know that ${my.property} should be expanded for <echo> as against for
     <replace> 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 <javac /> means
    <javac/> and not <javac x=y.../>. (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