Hi,
Here's an update on my latest work on QDox.
Last week I've been working on redefining the classlibrary. This was required
to be able to refactor the JavaModels.
I've added the com.thoughtworks.qdox.library-package, which contains several
new classes.
- ClassLibrary, interface publishing only the required methods
- AbstractClassLibrary, abstract class containing logic on how to resolve
classes, sources and packages
- ClassLoaderLibrary, bundles classloaders and uses the BinaryParser to build
the model.
- SourceLibrary, bundles sources and uses the FlexParser to build the model
- SourceFolderLibrary, extends SourceLibrary and tries to resolve a class based
on it's predicted path
- ClassNameLibrary, just build a simple JavaClass based on the name (it's like
the createUnknownClass-method from JavaDocBuilder)
The power of these libraries is that they can be chained. In fact you could
compare it to the classloader mechanism of java itself.
This will also answer to one of the questions on the user-mailinglist to be
able to reuse JavaModels.
To help building up these classes I've added a ClassLibraryBuilder, an
interface with which you can build the ClassLibrary.
I've created two implementations:
- SortedClassLibraryBuilder, which only has the four mentioned Libraries. Based
on what's added (InputStream, Reader, SourceFolder, SourceFile) it'll add it to
the right classlibrary.
- OrderedClassLibraryBuilder, which starts with the ClassNameLibrary. Based on
what's added it'll decide if it has to chain another library before adding it.
The JavaDocBuilder is bound to almost every important part of QDox. The way its
current constructors are used it's pretty hard to safely refactor them.
Also it's kind of weird that a Model needs to have knowledge of a
JavaDocBuilder. So I decided to make a new and clean version:
JavaProjectBuilder.
Its task is to build up the library and give it acces to this library. Besides
that the Builder has some handy methods (serializing, deserializing, add a
sourceTree)
Right now it has almost every method the JavaDocBuilder has and when running
the junit tests with the JavaProjectBuilder 69 of the 72 succeed.
Current failing reasons:
- testGetPackagesShowsOnePackageAndTwoClasses(): The order of JavaPackages
seems to have changed. The order of JavaProjectBuilder is exactly the order in
which they are parsed/used. Still have to find out how the order was calculated
before.
- testRecordFile(): if a FileStream or URL is parsered, it's source isn't
registered yet. I'll do that after refactoring the JavaModels
- testContinuesProcessingAfterBadFileIfCustomHandlerPermits(): ErrorHandler
hasn't been implemented yet. Something I want to solve at the end.
QDox contains its own implementation of OrderedMap. In its comment it says that
this is done because jdk1.3 doesn't have such implementation, but jdk1.4 does.
Since the target in the pom is already 1.4 I suggest to remove our own
implementation of OrderedMap and just use the java.util.LinkedHashMap.
Cheers,
Robert
