[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Cp-tools-discuss] bug + possible fix (patch) in texidoclet: TreeNod
From: |
Alex Lancaster |
Subject: |
Re: [Cp-tools-discuss] bug + possible fix (patch) in texidoclet: TreeNode.java |
Date: |
23 Feb 2002 19:57:22 -0800 |
User-agent: |
Gnus/5.09 (Gnus v5.9.0) Emacs/21.1 |
>>>>> "JS" == Julian Scheid <address@hidden> writes:
[...]
JS> I expect the proper solution is to use the package name of the
JS> current class (the "context" class) and append the non-qualified
JS> class name to this, using the result for deducing the TexiDoclet
JS> node name. However we need to be careful here, w.r.t things like
JS> Inner Classes etc.
JS> It could be that the interface class name supplied by gjdoc ought
JS> to be fully qualified but isn't, which is why this problem doesn't
JS> occur when using javadoc. In any case, this is a bug because you
JS> also have to be able to generate docs for classes in the unnamed
JS> package, whose names don't contain a period by definition (if it
JS> is not an Inner class.)
I think the problem is something like this because when I used the
"standard" doclet via javadoc and then via gjdoc I got missing or
additional qualifiers with some inner classes and such with gjdoc.
JS> Perhaps we should test TexiDoclet using javadoc and a bunch of
JS> classes in the unnamed package to see how it behaves in this
JS> situation. In this test scenario, we also should include a class
JS> which implements an interface which is located in the unnamed
JS> package.
Sounds good.
Alex