ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Donald <>
Subject Re: [DISC] Aspect Representation was [DISC] Aspect implementation
Date Sat, 02 Jun 2001 15:01:09 GMT
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
>   <fileset ant:id="blah.fileset"/>
>   <fileset refid="blah.fileset"/>

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. 


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

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

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.



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

View raw message