Jose Alberto writes: > I do not think we should tie location of tasks with > priviledge. For example > <property> does not need more priviledges than <available>, they both > just set the value of properties. However we like one at > project level and the other not.
Why exactly is that? if you're setting a property with <available> it seems perfectly reasonable to be able to do that at the top level if that sort of thing is to be allowed. As an Ant user, I'm at the mercy of the Ant core authors as to whether or not I can define this at the top (thereby making it available to all targets) or whether I have to do a bunch of dependencies on each and every target. That said, I can *almost* buy off on the concept of putting <taskdef> and <property> (and <available> and other "tasks that declare things" at the top level IF you're talking about implementing real scoping, i.e. if doing <taskdef> and <property> inside a target means it is no longer available outside that target. The logical extension of that, I might suggest (though I'm not sure yet whether I'd advocate), is the ability to declare a <target> inside another <target>, effectively making private targets. We are talking about scoping. :-) But what we have now is a mishmash of stuff inside and outside targets that effectively have the same scope - from the point of declaration until end of execution - so an <init> task (or whatever name you like) is at least a place that can provide some clarity and commonality. Your suggestion of using an interface is much better than what we have today (hardcoded) so I think it is the minimum solution - but it only addresses the task developer. The reason that I suggested the <init> task in the first place was to provide that clarity and commonality to the Ant *user*, and increase the maintainability of the build.xml files. Tim
