Re: [DISC] Aspect Representation was [DISC] Aspect implementation

[Peter Donald <do...@apache.org>]

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               |
*-----------------------------------------------------*