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
