Re: [aspectwerkz-dev] Creating AOPified javadocs

I think that mimic-ing the ajdoc architecture will allow better help from
Mik and may allow f.e. implementing an AspectBrowser (this little app that
generates a picture showing the crosscutting accross different classes thru
a bar chart).
If you volunteer on that, you have the lead as regards the architecture ;-)
Lets see what Mik and Jonas think.
Alex
PS: no need to parse sources to extract annotations on Java 5.
----- Original Message ----- 
From: "the_mindstorm" <[email protected]>
To: <[email protected]>
Sent: Friday, August 27, 2004 11:13 AM
Subject: Re: [aspectwerkz-dev] Creating AOPified javadocs


> Quote Alex::
>
> > 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
>
> My 2cent:
> - i think the sources are however parsed in a why (in order to
extractavadoc/annotation pointcuts)
> - extracted info from above step is combined with loading xml defs in
order to establish the weaving
> strategy
> I think these 2 steps can be reused for the aopdoc tool.
>
> The idea of emitting events from weaver at joinpoints is very good, but it
must be combined with
> some source parsing (in order to use the initial javadocs and also to
retrieve the applyed pieces of
> advice).
>
> The last 2 steps (e.g. generate stubs and run javadoc) are necessary and I
think this is the only
> way we can do it.
>
> ::the_mindstorm
>
> PS: it is still not clear for me what you meant by saying integrating AJDT
:-(.
>
> >
> > 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.
> >>>>
> >>>>
> >>>>
> >>>
> >>>
> >>>
> >>
> >
> >
>
>