I would personally prefer a slightly more distinct syntax that didn't use ${} for things that arn't exactly properties. Looking at it another way: your suggestion is a half-magic property :) It reserves property names starting with macroattr: and macrotemplate: as special, and different from other properites.
Templates appear to be something new, though I don't think I like them (see below)
(1) --> ${xyz} (2) --> ${macroattr:xyz} (3) --> ${macrotemplate:xyz}
Well, as I said I use those terms above just as examples, I am not
hookup in words, I was just looking for some identifier to describe them. Still the
concepts
I am expressing are very clasical ones, these are not things out of the
blue.
I hadn't realized that taskdefs did this, but if it were up to me I wouldn't have designed it this way. I would prefer to see the taskdefs in each build file, so that I don't have to find out who's calling the buildfile to find out where to find out what the task does. Any time you get that many find-outs in a sentance it is clearly a royal pain in the making (imho). :).If macro definitions are available to sub builds, then your 3rd case might occur, but I don't think it would be good to allow macros to be called across build file boundaries. builds would be almost unintelligible without tracking down the macros from other files.
This is all regular kosher ANT stuff, up to this day, <taskdef/>s get
inherited, they do not need to be redeclared for the task to be
available
during the <antcall/>. Are you proposing that we have a different,
special case,
semantics for <macrodef>?
In otherwords, I would have prefered the simple rule, "if it isn't part of the standard distro of ant, there will be a taskdef in the build to tell you what it is." I don't think saving a few extra lines of typing (or cut/paste) for the taskdefs is really worth making the build unreadable without reference to another build (which won't be known unless it appears in a comment).
I havn't followed the antlib topic closely enough (I havn't followed it at all really because of the sheer volume of mail on those threads, and the need to get some of my own work done :) ), but I get the impression that antlib might reasonably eliminate the taskdef stuff by creating a single place to look for definitions of things that arn't part of the standard distro. and that would be fine. I only object to having to having the builds depend on things defined in other builds with no pointer to the definition (or standard location for the definition).
-Gus
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
