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