At 07:28 PM 6/2/01 +1000, Conor MacNeill wrote: >> * Only the top level task element has aspect "attributes" (though this >> would change with container tasks - more on this later) > >Actually if you consider the id attribute in Ant1 to be a primitive form of >Aspect, it can occur in any XML element. So, I can define a fileset nested >deepy in some task's model and have that fileset referenced elsewhere. >Something like this > ><blah> > <fileset ant:id="blah.fileset"/> ></blah> > ><blah2> > <fileset refid="blah.fileset"/> ></blah2>
In this particular use case I don't think we should support it. If the user wants named filesets rather than anonymous ones they should define them outside task. Then all tasks that use fileset refid it ;) >Now when I dealt with that in mutant, I wondered whether we should continue >to support that or only allow data type values to be defined at the top >(task level), if you know what I mean. +1 >Anyway, it is a usecase of aspects >occuring at the element rather than task level. Thoughts? no idea - I can think of use cases when writing container tasks. But not otherwise - though haven't really played with it much. It just starts to get complicated for us to do I guess. >> I believe that application of these rules will allow most aspects to be >> built but still allowing ease of implementation for both us and the >aspect >> writers. >> >> It will also be simpler IMHO for build file writers ... though I am not >> sure about this yet. Need to test it more. >> >> Thoughts on this? >> > >We have basically agreed on the TaskContext concept to define how tasks >interact with the core. I extended this in mutant to become an >ExecutionContext with is passed to both tasks and aspects. What do you >think? personally I can't seen any reason to allow task writers in general to access (or even know about) aspects or taskdefs etc. In a few cases it may be relevent (ie aspect-def/task-def tasks) but they should be treated as special cases rather than general run of the mill. In my experiments I founf there was generally two types of tasks. "Privlidged" tasks and un-privlidged tasks. The privlidged tasks get access to interfaces that allow them to interact with the ant runtime. Example privlidged tasks would include; * type-def tasks like aspect-def, task-def, mapper-def etc. (Need access to TypeManager/Registry). * ContainerTask - needs access to Task model and Execution engine (and possibly access to the converter service to "interpret" it's own attributes). * Facility tasks (ie like recorder for Ant1) that "install" an aspect. * ant-call/ant/etc need access to Project model, ProjectManager and possibly the ProjectBuilder. >If not, what sort of interface should we provide to aspects from the >core? Personally the only interface I think we should provide is one to install/uninstall a aspect. The event direction between tasks/aspects is mediated by the runtime who has complete control over that. Cheers, Pete *-----------------------------------------------------* | "Faced with the choice between changing one's mind, | | and proving that there is no need to do so - almost | | everyone gets busy on the proof." | | - John Kenneth Galbraith | *-----------------------------------------------------*
