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:[EMAIL PROTECTED]] Sent: Friday, November 22, 2002 5:03 PM To: 'Jon Tirsén'; [EMAIL PROTECTED]; [EMAIL PROTECTED] Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; '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:[EMAIL PROTECTED]] Sent: Friday, November 22, 2002 2:50 AM To: [EMAIL PROTECTED]; [EMAIL PROTECTED] Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; 'Jakarta Commons Developers List' Subject: RE: runtime attributes > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] > Sent: den 20 november 2002 14:14 > To: [EMAIL PROTECTED] > Cc: Jon Tirsén; [EMAIL PROTECTED]; [EMAIL PROTECTED]; > [EMAIL PROTECTED] > 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:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
