Re: [aspectwerkz-dev] Creating AOPified javadocs

wether there is
javac + weave classes + generate stubs and javadoc  [method 1 and method
with emitted join points]
or
parse sources + generate stubs and javadoc

Do you think it is ok to code the "parse source" part with QDox by matching
the join points ? - that is somehow:
- load all the xml defs, grab the def from annotation defined aspect as well
- for each class, build what we call the metainfo from Qdox, this one will
be used in the pointcut expression matching mechanism
- for each construct types (method execution , method call etc), check if
there is a match.

I think it is not easy to do with QDox, especially for call pointcut - that
occurs at the method body level - something that QDox is ignoring since it
is not the goal of QDox. For such a need, you need a more rich parser, or
something like the IntelliJ PSI structure interface - but then it gets IDE
specific.

Alex

----- Original Message ----- 
From: "the_mindstorm" <[email protected]>
To: <[email protected]>
Sent: Friday, August 27, 2004 9:07 AM
Subject: Re: [aspectwerkz-dev] Creating AOPified javadocs


> Alex wrote:
>
> > Hi
> >
> > Mik will comment on method 1.
> >
> > As regards method 2, we have a new weaver under dev that will "emit join
> > point". I guess that if we extend it to have a listener to that, we can
> > probably do the weaving not on the sources but on the "javac compiled
> > classes" ie fully reuse the regular weaver and avoid developping
another.
>
> Still, a pre-compile step is still needed, ain't it?
>
> > Moreover, if javac debug mode had been turned on, we can emit the source
> > code line number of the join point I think.
>
> Possible, but I don't think we can rely on this. Production code will not
be
> compiled with debug switch (I guess so, at least this is what we are
doing).
>
> > Then the tool consumes the emitted join point (each notification has a
bunch
> > of data, that might even allow avoiding qdox resolution of
java.lang.reflect
> > resolution)
>
> Pls be more clear [sigh/]. I didn't get the above.
>
>   and could "patch javadocs" - though I think having regular
> > javadoc processing on some empty stubs might be better.
>
> ajdoc and my solution both use the javadoc processing on empty stubs. The
1st
> steps are different.
>
> >
> > Well, this is not ready yet, but, what do you think ?
> >
> > The drawback of method 2 is that - I guess - doing the method 1 way
might
> > open more opportunities to further integrate AJDT.
>
> What you mean by [quote]integrate AJDT[/quote]?
>
> ::the_mindstorm
>
> >
> > Alex
> >
> >
> > ----- Original Message ----- 
> > From: "the_mindstorm" <[email protected]>
> > To: <[email protected]>
> > Sent: Thursday, August 26, 2004 11:39 PM
> > Subject: Re: [aspectwerkz-dev] Creating AOPified javadocs
> >
> >
> >
> >>Hi!
> >>
> >>I finally got some time to look into ajdoc implementation.
> >>
> >>If i got it right the process used is the following:
> >>- compile the sources (weave aspects in)
> >>- generate fake/stub sources (including only declaration and javadoc
> >
> > comments)
> >
> >>from weaved classes
> >>- run javadoc upon the stubs
> >>- inject aspect related directly into html
> >>
> >>This seems to me a pretty complex and long process (2 memory extensive
> >
> > consumers
> >
> >>are run: weaving (AspectJ compiler) and javadoc).
> >>
> >>The draft solution I have in my mind is the following:
> >>- using QDox extract all joinpoint definitions
> >>- solve joinpoint definitions upon available sources
> >>- inject specific javadoc comments into the QDox structures
> >>- write down stubs generated by QDox
> >>- run javadoc upon stubs using a specific doclet
> >>
> >>Please give me your impressions/opinions on the above. 10x
> >>
> >>::the_mindstorm
> >>
> >>PS: by the way, I am still using a nickname and I was not presenting
> >
> > myself:
> >
> >>Alexandru Popescu.
> >>
> >>
> >>
> >
> >
> >
>
>