Re: [Fwd: Re: [aspectwerkz-dev] Creating AOPified javadocs]

<Quote>
> > phase 1 and 2 are gone with J2SE 5.
> 
> The solution must not take to much into account this, as i consider that the switch to J5 will take
</Quote>
How about Tiger's javadoc? How does he solve *annotation* in javadoc?

P.S: I am a stranger to Tiger

/Jack



On Fri, 27 Aug 2004 18:59:40 +0300, the_mindstorm
<[email protected]> wrote:
> 
> Quote Alex::
> 
> > 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.
> 
> Correct. This is why I am thinking that the 1st solution is more suited.
> 
> >
c
> a long time.
> 
> > 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).
> 
> Interesting. I missed this. Alex can you pls detail a little this mechanism.
> 
> An interesting point is that the javadoc will use the compiler/weaver in offline mode (or will use
> the inline weaver ;-) ).
> 
> > 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.
> 
> There are intentions in AW to support all the AspectJ features? Is there a roadmap?
> 
> ::the_mindstorm
> 
> 
> 
> >
> > 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
> >>
> >
> >
> >
> 
>