Re: [aspectwerkz-dev] Creating AOPified javadocs

Hi
Looks like you forgot the diagram.
How will you handle call pointcut matching at source level (and not bytecode
level) with QDox ? I don't think it is possible, since QDox does not
modelize method bodies.

phase 1 and 2 are gone with J2SE 5.
phase 3 is wrong may be: we do not parse javadoc tag. We parse annotations
in bytecode (that get there thru AnnotationC or J2SE 5 javac).
phase 4 is : weave class files as they gets loaded thru classloaders (not
java sources)
Or may be you confused me , since I made the assumption that those phases
were executing one after another.

Some more ideas: As you may know AspectJ has a declare error construct that
allows to report design error based on pointcuts (ie : do not call new
Stuff() unless within the factory method code etc). The tool design and the
underlying weaver requirements should handle this as well.

Alex

----- Original Message ----- 
From: "Jack Tang" <[email protected]>
To: <[email protected]>
Sent: Friday, August 27, 2004 4:53 PM
Subject: Re: [aspectwerkz-dev] Creating AOPified javadocs


> Hello Alexandru
>
> After reading Alex's comments, I think I got some points. If something
> wrong, please correct me, Alex.
>
> The key of this problem is when to collect aop model information and
> who will supply these information. Two solution list here:
>
> 1.javac + weave classes + generate stubs and javadoc  [method 1 and
> method with emitted join points]
> 2.parse sources + generate stubs and javadoc
>
> And I divide AW engine workflow into five phrase(maybe more,but here
> I think five is enough).
> 1.hook phrase      : pipe BootClasspathStarter/JDWPStarter after
> java.lang.ClassLoader
> 2.preProcess phrase: initialize preProcessor,filter certain CL and modify
CL
> 3.parse phrase     : parse xml and javadoc @tags
> 4.compile phrase   : compile Java source
> 5.transform/weave phrase: weave the cross-cutting info
>
> diagram like this:
> (see attached file)
>
> Let's discuss solution 2 first. We should parse java sources by
> ourself using QDox, then parse xml def, finally we structure aop
> domain model by our hand. This solution is better to me first
> impression, because I dream he can avoid "compile phrase". But maybe
> it's my daydream.
>
> And if we refer to solution 1, "compile phrase" has to be involved,
> but we can access aop domain model easily through weaver context.
>
>
> /Jack
>