ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Conor MacNeill" <co...@cortexebusiness.com.au>
Subject Re: [DISC] Aspect Representation was [DISC] Aspect implementation
Date Sat, 02 Jun 2001 09:28:40 GMT

----- Original Message -----
From: "Peter Donald" <donaldp@apache.org>
To: <ant-dev@jakarta.apache.org>
Sent: Saturday, June 02, 2001 3:23 AM
Subject: [DISC] Aspect Representation was [DISC] Aspect implementation


> At 11:30 PM 6/1/01 +1000, Conor MacNeill wrote:
> >I'd like to initiate a discussion of aspect implementation. I think we
have
> >some level of agreement that we will have aspects but no real clear idea
> >about how they will look.
>
> I am not so sure about that ;) I think first we should discuss how things
> will be represented in buildfile first,

Sure. Good idea. I wasn't trying to force an implementation. Just after
doing some prototyping I had found some issues and thought it was an
opportune time to talk through them and see what other people think an
aspect is going to be.

> what type of aspects we will
> support and then finally goto implementation ;) This was on my list of
> things to discuss before I stopped sending them out.
>
> First - representation. Currently I would prefer to support the following
> style of aspect integration
>
>  <mytask ant:id="foo" ant:classpath="..." ex:fail-on-error="false">
>    <doc:description>Blah blah blah.</doc:description>
>    <some-sub-element ... />
>  </mytask>
>
> The important points in the above example are;
> * aspect "elements" (ie doc:description) do not have any attributes or
> sub-elements from another namespace

Hmmm, I hadn't even really considered aspect elements. I guess they are
cool.

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

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?

>
> 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? If not, what sort of interface should we provide to aspects from the
core?

Conor



Mime
View raw message