Re: [aspectwerkz-dev] Creating AOPified javadocs

Quote Alex::

> I think that mimic-ing the ajdoc architecture will allow better help from
> Mik 

true :-)

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).

not quite sure about this

> If you volunteer on that, you have the lead as regards the architecture ;-)
10x

> Lets see what Mik and Jonas think.
> Alex

the help of Mik and Jonas will be very important for me.

> PS: no need to parse sources to extract annotations on Java 5.

sure, i know this


Can you point me to the new weaver implementation? Is it on cvs now?

::the_mindstorm

> ----- 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.
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>>
>>>
>>
> 
>