commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jon Tirsén <...@tirsen.com>
Subject RE: runtime attributes
Date Fri, 22 Nov 2002 07:50:04 GMT

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