commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mark Pollack" <mpoll...@speakeasy.org>
Subject RE: runtime attributes
Date Fri, 22 Nov 2002 22:06:13 GMT
Sorry, I realized that my last email didn't line break quite right on
the last paragraph..


<snip>

I'm not sure I understand point 3, can you explain better.  Is the
exteral file that contains the metadata self describing enough so that
it can be extracted by an AttributeReader easily?  Something like 


attribute.class.<class tag name> = <class tag value> attribute.

field.<field name>.<field tag> = <field tag value> 

attribute.method.<method name>.<method signature>.<method tag> = <method
tag value> 

This should be easy to create an API to read this file in the
implementation of the AttributeReader that can take java.lang.reflect
package classes as arguments.  The only trick part is the method
signature, but that isn't that bad either

</snip>

- Mark


-----Original Message-----
From: Mark Pollack [mailto:mpollack@speakeasy.org] 
Sent: Friday, November 22, 2002 5:03 PM
To: 'Jon Tirsén'; aslak.hellesoy@bekk.no; mpollack@speakeasy.net
Cc: ara_e_w@yahoo.com; mpollack@speakeasy.net;
james_strachan@yahoo.co.uk; 'Jakarta Commons Developers List'
Subject: RE: runtime attributes


Hi,

Why just adjust the interface between the Writer and Extractor to be
more self-describing?  It seems that qdox offers enough metadata as the
standard javadoc doclet as far as our needs are concerened.  I agree
that the coupling between the two should be well defined, either if this
is an exchanged object between the two or qdox/javadoc indepenent
methods that the writer exposes to the extractor.

It seems the motivation for xjavadoc is code mutation, not required by
us. qdox is speed which shouldn't be a concern at the moment.  What
features are lacking in the qdox api? I don't see a need for a new
javadoc parser project.  Sorry if I am missing something.

The Qdox api seems to already offer access to the metadata we normally
associate with 'java.lang.Class,Method,Field or
javadoc.ClassDoc,MethodDoc,FieldDoc.  That is you can drill down the the
qdox.JavaParameters[] of the method.  Based on this we could come up
with a simple self describing class to pass between the Extractor and
the Writer, or just have the extractor call well defined writer methods
(preferred way?).  These methods do not have to depend on the qdox api
if we don't want to - we can use a String array to define the method
parameters.  In the case of an implementation that uses qdox, these
would come from JavaParameters[], in the case of a doclet implementation
they would come from MethodDoc.  In Attribj4, I changed the 'writer'
interface (ClassAnnotator) to accept a javadoc.MethodDoc paramter, but
that was before I wrote a utility class for bcel to convert its method
signature from the jvm way (IJ) to a string array [int, long].  Actually
now I realize that I should put that method back to the orignal way
since I never liked that dependency there and I was not aware of qdox at
the time.

I'm not sure I understand point 3, can you explain better.  Is the
exteral file that contains the metadata self describing enough so that
it can be extracted by an AttributeReader easily?  Something like 
attribute.class.<class tag name> = <class tag value>
attribute.field.<field name>.<field tag> = <field tag value>
attribute.method.<method name>.<method signature>.<method tag> = <method
tag value> This should be easy to create an API to read this file in the
implementation of the AttributeReader that can take java.lang.reflect
package classes as arguments.  The only trick part is the method
signature, but that isn't that bad either.

Cheers,
Mark



-----Original Message-----
From: Jon Tirsén [mailto:jon@tirsen.com] 
Sent: Friday, November 22, 2002 2:50 AM
To: aslak.hellesoy@bekk.no; mpollack@speakeasy.net
Cc: ara_e_w@yahoo.com; mpollack@speakeasy.net;
james_strachan@yahoo.co.uk; 'Jakarta Commons Developers List'
Subject: RE: runtime attributes



> -----Original Message-----
> From: aslak.hellesoy@bekk.no [mailto:aslak.hellesoy@bekk.no]
> Sent: den 20 november 2002 14:14
> To: mpollack@speakeasy.net
> Cc: Jon Tirsén; ara_e_w@yahoo.com; mpollack@speakeasy.net;
> james_strachan@yahoo.co.uk
> Subject: RE: runtime attributes
> 
> I think it would be good to add some more abstractions to the API: o 
> AttributeExtractor - Reads attributes from source code. SPIs: 
> XJavadoc, QDox, > Doclets o AttributeWriter - Writes attributes 
> somewhere. SPIs: BCEL, serialisaton, XML, > Properties o 
> AttributeReader - Reads attributes from somewhere.

Okay, I had a try at refactoring the current implementation into this
yesterday. I like the general idea very much but there's a couple of
problems we need to work out. This is the dynamic model:
1) The Ant-task uses the Extractor and the Writer.
2) The Extractor creates ClassAttributes (I'm still not convinced on the
name ClassMetaData :-) from whatever it creates them from and the
Ant-task sends them to the Writer to be written to whatever it writes
them to.

The problems are:
1) Dependency checking. We need to have an abstract way of checking all
the modification-dates of all the in-data that the Extractor needs
(which is _not_ only the .java-files, we can't possibly assume that, it
could be the .java-files, it can be property-files, XML-files, heck it
could even come from a database). This date should be newer than the
out-data the Writer produces (where we can't assume anything either,
.ser-files, property-files, database and so on).
2) The contract between the Extractor and the Writer. It would be good
if the contract would only require the ClassAttributes/ClassMetaData but
if that is the case it needs to be self-describing and can _not_ rely on
Class, Field, Method and so on because these are not available at
compile-time (since the classes has not been compiled yet). This
basically means we need the unified source-code API you were talking
about (unification of the Qdox and the XJavadoc-APIs). So we would need
that API to create this. Is it tough to create that API? Could we start
up a new Commons-project for that and have it ready in no-time? Should
we start it up here in commons-attributes and then move it out?
3) Last, and this gives me even more heartache: If the ClassAttributes
should need to rely on the compile-time JavaSource-API at compile-time
it should need to do this at runtime too, _if_ we don't want to create
two different interfaces. CompileTimeClassAttributes and
RunTimeClassAttributes. I don't think we want that. But this means we
need to marshal the JavaSource-model so that it is available at runtime
too... If it's a very lightweight API (sort of like the Qdox-API) it's
not a major problem, if it's gonna be more like the XJavadoc-API it's
gonna be a nightmare.

Please, let me know your opinions on this.






--
To unsubscribe, e-mail:   <mailto:commons-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:commons-dev-help@jakarta.apache.org>


Mime
View raw message