nice. On Sun, Oct 3, 2010 at 8:45 PM, Robert Scholte <[email protected]>wrote:
> 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 > > >
