Description Andrew Clement 2008-06-18 16:54:51 EDT

From Chris Beams.

He has an environment where he uses development aspects in his project to police certain things.  At the same time he also has some malformed aspects where he wants to produce his own suitable error messages.  Effectively he has something like:

import org.aspectj.lang.annotation.*;

@Aspect
public class Broken {

@Before("bogus")
public void m() {}
}

And basically he wants to pass it through ajc with the rest of the code, but does not want it treated like an aspect, rather have it treated as if it had been through javac.

We have the option -Xdev:NoAtAspectJProcessing but that just stops any processing during the compilation stage (ajc does extra processing when encountering annotation style aspects if it can), and the weaver then fails with an error about the pointcut instead.

options we have just talked about:
- an annotation on the type that marks it as 'leave me alone'
- a comment style thing //AJ:OFF
- ui preference for a project that specifies a pattern (pointcut?) on what to exclude

Only the first of those appeals to me right now.

This would actually aid our own aspectj testing as it is hard to test some annotation style problems because we dont easily have a well known level of javac defined that we can use, but we *do* have ajc, we just cant configure ajc to behave like javac right now.

We also have the flag -XterminateAfterCompilation.  However, both this and the NoAtAspectJProcessing are global, they are not fine grained controls that allow behaviour to vary on a per-aspect basis.

If -Xdev:NoAtAspectJProcessing were extended with a regex list, I wonder if that would be enough:

-Xdev:NoAtAspectJProcessing:(com.foo.something.*,com.goo.something.IgnoreMe)

I know a pointcut is ideal but faking up enough environment to parse a pointcut on the end of an option would be hard.

The problem is to ensure the weaver doesn't go digging around for pointcuts/itds/etc in the types and right now it does that through many routes.