ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From peter reilly <>
Subject Re: [new tasks] presetdef and macrodef
Date Thu, 14 Aug 2003 16:21:40 GMT
On Thursday 14 August 2003 15:23, Dominique Devienne wrote:
> After all the praises, I hope my post doesn't sound too negative. 
No problem.
> I also
> think it's a great addition Peter, I just have a few reservations ;-)
> See below... --DD
> > -----Original Message-----
> > From: peter reilly []
> >
> >
> > <presetdef> (formally known as extendtype)
> >   this defines a new task or type based on a current ant task or type,
> >   with attributes or elements preset.
> >
> >   example useage:
> >   <presetdef name="my.javac">
> >        <javac debug="${debug}" deprecation="${deprecation}"/>
> >   </presetdef>
> >
> >   <my.javac> may now be used as a task in the same way as <javac>
> >   but the attribute debug and deprecation will be preset.
> I'll start by neat picking ;-) What <presetdef> does is binding a given
> value to a task attribute. In the C++ world, the method to do that are call
> bind, which is IMHO better that preset.

<presetdef/> also allows nested elements to be predefined - or bound.

> Also, this kind of static attribute-binding is useful indeed (I've actually
> asked for it a few times), but is hardly a definition, and it's bad that it
> forces you to rewrite the task name. I don't want to modify all my builds
> to use <my.javac> just to take advantage of that feature.
> Finally, <presetdef>, in term of functionality and not implementation, is
> just a subset of <macrodef> in my opinion, and doesn't deserve Task status.

It is not a sub-set of <macrodef/>. But there is a lot of overlap of
functionality. In fact after I got embeded elements to work for <macrodef/>,
I replaced most uses of <presetdef/> with <macrodef/>.

I think however that there is a place for <presetdef/> For example
if you look at the current code of TaskDef, all it consists of is
setting two properties. This can be expressed using <presetdef/> as

<presetdef name="taskdef">
	<typedef adaptor=""

When (if) roles are introducted, one implementation would be
to add a "role" or "restrict" attribute to <typedef>.

  <typedef name="or"

  <typedef name="or"

one could use <presetdef/> as
   <presetdef name="conditiondef">
and define:
    <conditiondef name="or"

> Much more useful IMO was be the ability to bind (or preset) values using
> XPath expressions, to follow your example:
> //javac/@debug = ${debug}
> //javac/@deprecation = ${deprecation}
> To just do it for an instance of Javac inside a particular target, do
> //target[@name='compile']/javac/@debug = true
> I've always been annoyed to having to explicitly declare a bunch of task
> attributes taking properties when sensible default values just to be able
> to maybe override them.
> So in conclusion, I'm +1 to the ability to bind values to task/type
> attributes, but without requiring task name changes, and possibly with
> requiring a task. I'm -0 to <presetdef> as it is.
> A middle ground would be to have something like this, closer to your
> current design:
>   <bind-attributes>
>     <delete quiet="true" />
>     <javac debug="${debug}" deprecation="${deprecation}" />
>     <exec failonerror="true" />
>   </bind-attributes>
> So it yields no task rename, work for any valid tasks, and is more
> explicit.

True but not easy to implement (I think, although.....) and does
something different to <presetdef/>.

> > <macrodef>
> >       </compile-exec>
> <macrodef> I have much less problem with, but I concur with others that
> overloading the behavior of ${name} is not good. This will be confusing to
> me and other users that property expansion will not happen as usual at
> definition time, but later on.

All of the expansions happen later on.  If the macro is used in a different
project to the project it is defined in, the properties in use will be of
the project that the macro is used in*. However, I can see
that there can be issues with using the same notation for the macro
expansion of attributes and then normal expansion of properties.
I am loath however to adding new rules for indicating variables.
However if ant people want a different encoded for the macro variables,
I would have no objection.

* This is different to <expandtype> where the project of the definer
   is used to evaluate the preset attributes and elements.
   This is a reason I called the second task <macrodef/>, one
   should consider it a lump of xml to be placed in at the current
   location with substitutions of attributes and elements.
> I think we need another syntax for the macro
> param/attributes, and keep the ${} working as usual.
> I propose to use either:
> * the XSL syntax (@name)
> * or a Javadoc-like syntax {@param name}
> Another advantage of the second form is that one would not need to
> pre-declare the macro params (making it scripting-language-like), but on
> the other hand, pre-declaring makes it more explicitly when reading the
> macro what parameters it takes. If we force pre-declaration, we can then
> fail on dereference to non-declared macro-param.

Yes, The current code does these checks.

> Should param be renamed attribute? <macrodef>, from the build writer point
> of view, creates a new tasks, and we always speak of attributes and nested
> elements, not params and nesting elements.

I picked param, as some other tasks use param (foreach*,
antcall) for something similar.

* Locally I have modified foreach to behave the same way as macrodef,
  (i.e run a sequential task in the same project with the different values of 
  the list or path) 

Cheers Peter.

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

View raw message