ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From peter reilly <>
Subject Re: Getting 1.6 out the door
Date Mon, 01 Sep 2003 18:10:41 GMT
On Monday 01 September 2003 16:43, Dominique Devienne wrote:
> > -----Original Message-----
> > From: peter reilly []
> >
> > > 3. <macrodef> and <presetdef>
> >
> >   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.
> >
> >      I think that the current implementation and behaviour is
> >      preferable.
> I think it's sad that you reflect on this from the implementation
> perspective rather than the user's one... One of the major 'feature'
> of Ant is that it is very explicit and relatively simple.

The problem is that I do not know how (or if it is possible) to implement the
feature of expanding the properties at definition time.

> It's not all about power, or one would use a real programming language
> like Perl or Python. <macrodef>, although powerful, complexifies the rules
> of Ant, namely the property expansion one, making it context dependent!
> Never underestimate the power and simplicity of context/scope free rules.
> Although Ant already has scopes with <ant>/<antcall>/<subant>, the
> expansion rules works the same everywhere, and I'd like this to stay the
> same.

<macrodef> follows (I think) the same rules of properties as <antcall> with

  <target name="">

  <target name="do.echo.test">
    <macrodef name="do.echo.task">
    <antcall target="">
      <param name="do.echo" value="Hello world"/>

<macrodef> should make ant a little simpler by removing the need
for a lot of <antcall>s. People sometimes use them at the moment to emulate

Normally (I think), <macrodef> would be used in the same project that defined
it, so the rules for property expansion would not be an issue.

> >   b) syntax of attributes
> >      After using macrodef for a little while (well mostly in writing
> >      examples), I think that ${name} feels the best.
> That's one opinion. You obviously don't mind complexity yourself b-)
> I, OTOH, prefer things clear&simple, with the least possible surprise.

Ok, after using perl, I do not like the idea of having different
syntax for different (but similar) things.

> >      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.
> Wowwww, hold on! We're not turning Ant into a programming language,
> remember?
But it is one of the objectives/consequences of ant-contrib/antelope.
One would like to do things like:
<notation:warning name="Use of ant as a progamming language"
        <foreach param="file">
                <fileset dir="${test.dir}/mains" includes="*.cpp"/>
                <pathelement path="src/shell/probesh.cpp"/>
                    property="program"  input="${file}"
                    regexp=".*/([^\.]*)\.cpp" replace="\1"/>
                 <compile-exec program="${program}">
                       <path path="${file}"/>
                 <compile-exec-file file="${file}"/>
     without the "program" property being visible outside the foreach
     sequential element.
> >      However this (unlike a) is easy to code for :-), if ${name} syntax
> >      is not liked my other preference would be ${macroattr:name}.
> Sigh... Again, this notation would introduce a subtle variation on property
> expansion, which may indeed be backward incompatible. It's currently
> perfectly
> OK to have regular property names that for some reason start with
> macroattr:.

Ok, scratch ${macroattr:name}.

> Property interceptors are not part of Ant, and might never be for that
> matter.
> Using a notation that mimicks interceptors is probably not a good idea
> either.
> As I've been saying all along, lets just introduce a new (unique) notion
> for attribute/variable expansion (at use time rather than definition time),
> which
> is something new in Ant anyhow. No (or less?) backward compatibility
> issues, and makes it plain and obvious what is what:
> 	${name}	it's a property!
> 	(@name)	it's an attribute/variable!!!

yes but (IMO) this is confusingly similar to XPath use of variables.
  <macrodef name="cut">
    <attribute name="use">
      <xmltask source="input.xml" dest="1.xml >
        <cut path="web/servlet/context/config[@id='(@use)']"
             buffer="storedXml" />

> No context, no unnecessary brain cycles to figure out what is what.
> I'll be just as glad as the next guy to use <macrodef>, I just don't want
> that
> power to come of the expanse of Ant's simplicitly and user-friendliness.

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message