OK Robert, so they seem concrete improvements. Are they a series of discrete refactorings though, while keeping the unit tests passing?
- Paul On Wed, Sep 8, 2010 at 9:51 AM, Robert Scholte <rfscho...@codehaus.org>wrote: > Agree on 5 and also userfriendlyness would be my top prio. > > The "problem" I'm hitting the following issues: > - In QDox we're using both JavaClass and Type, but it looks like the usage > is a bit mixed up right now. > In the java-api Type is an interface which Class extends, unlike QDox, > which makes it a bit confusing. > In QDox the JavaClass is a non-array representation of a class, the Type > includes the dimension (and a bit more, because for some generic types the > dimension info is required). > Maybe our life would be easier if we could combine these two and have an > implementation for the Model and for the context, just as we had to do with > JavaPackage. > - Both the JavaDoc and JavaClassContext have a method called getPackages(). > The first one only returns the packages from source-classes, the other one > all used packages (incl. java.lang). I think the javaDoc.getPackages() > should use the context.getPackages(), but what should be the result? Right > now I think only source-packages should be returned. > - The JavaDocBuilder has some private methods for building a model > especially for the binaryBuilder. To keep the JavaDocBuilder clean, I think > we should move these to another class. > - JavaClass.getDerivedClasses() is about relationship with other classes, > that's why it is using the context. I have my doubts if model classes should > be aware of a context. Although I haven't thought of another spot yet... > > - Robert > > ------------------------------ > Date: Wed, 8 Sep 2010 09:14:23 -0500 > From: p...@hammant.org > To: dev@qdox.codehaus.org > Subject: Re: [qdox-dev] Thoughts on priorities? > > > Robert, what are the problems you're trying to solve? (is a good question > to start with). > > If I number your's below (1 - 4), I only hear mild complaint about 2. > Nobody from the user community complains about 1,3,4. > > May I suggest a 5: Ease of migration to a new QDox 2.x from a 1.x codebase > ? > > - Paul > > > On Wed, Sep 8, 2010 at 7:49 AM, Robert Scholte <rfscho...@codehaus.org>wrote: > > The following things are targets for which we all need the same focus. > Since they kind of rule eachother out, we have give them a prio-order. For > instance, making it more user-friendly might cause extra code, which will > make the jar grow. > In any order I come up with the following (maybe I'm still missing > some...): > * small jar-size > * user-friendly > * closer to java-api where possible > * compact/redundant code vs. inheritance/delegating methods > > Maybe there are some historical facts I'm not aware of, so please let me > know. > > - Robert > > > > > >
