--- Conor MacNeill <[EMAIL PROTECTED]> wrote: > > > > So before we define the Aspect interface I think > we should try to > generate > > a list of aspects that we think would be valid to > implement. > > That sounds a reasonable approach although I feel we > may be able to > identify the "hinge points" just from our > understanding of how Tasks will > be executed. The other thing I mentioned in a > separte post is identifying > to which elements or tasks the aspect is to be > associated. With a debugging > aspect, for example, we may want to apply to a > number of task types without > having to enter aspect style attributes into each > task declaration. This > might lead us into what AspectJ calls pointcut > designators. If so, we'll > need some syntax for that. Or is that too complex > for now. > > I don't think there will be many aspects in practice > but you neve know. > Anyway, the types of aspects to date I have > considered > failonerror control > id definition > debugging/tracing aspects > perhaps logging but I haven't thought about it. > > Your example contained a doc: aspect but I had > always theought that was > piggy backed to the aspect concept as a way of > ignoring some elements. That > is, I didn't really expect the core to process these > in anyway. Thoughts? > Do we agree that an aspect can be in the build file > without there being an > aspect handler defined for that and if so, those > aspect attributes are just > ignored > > Any thought about aspects applied to either target > or project elements? > > Let's see what other aspects people might find > useful > > Conor > >
__________________________________________________ Do You Yahoo!? Get personalized email addresses from Yahoo! Mail - only $35 a year! http://personal.mail.yahoo.com/
