Re: [Xdoclet-user] Resolving imported super-classes in XJavaDoc?

[Tom S. <tom...@be...>]

Yes, the classes I am trying to resolve against are definitely in my
classpath. If I have a class like this:

package bar;
import foo.FooBase;
public class Bar extends FooBase
{ ... }

Then everything works, I can see foo.FooBase as the superclass for Bar, and
I can go up to FooBase's superclass and beyond. However, if I do this:

package bar;
import foo.*;
public class Bar extends FooBase
{ ... }


Then I get an UnknownClass called bar.FooBase as the superclass for Bar, and
I can't go any further up the hierarchy (I just get java.lang.Object). All I
changed between the two examples is the sourcecode, the jars in the
classpath are the same, so the foo package with FooBase should still be
accessible.


>
> Tom Stamm wrote:
>
> >Hi, I'm running into some issues with resolving classes that
> have not been
> >explicitly imported. For example, say in a jar on my classpath I have a
> >class foo.FooBase, and then on my sourcepath I have a source file
> >bar/Bar.java that imports foo.* and extends FooBase.
> >
> >When I run my sourcepath through XJavaDoc, I get an XClass for
> bar.Bar but
> >it doesn't resolve FooBase to foo.FooBase, I get bar.FooBase
> instead. I see
> >from the warning message that XJavaDoc doesn't want to search
> all imported
> >packages for a class, so it assumes it is local. If I change my
> import from
> >foo.* to foo.FooBase, I get the correct type information, so I know my
> >classpath is correct.
> >
> >My problem is that I only want to process files that extend
> foo.FooBase...
> >is there a way to check for this? Maybe a flag I can set to
> force it to do a
> >full search, even if it will be time-consuming? I have a little
> hack where I
> >see if the class imports foo.* and extends an unknown class
> called FooBase,
> >but that seems pretty ugly!
> >
> >The strange part is that if bar.Bar has an inner class Baz, that extends
> >foo.SomeOtherFoo, Baz's type information comes up correctly, and
> I can get
> >the real foo.SomeOtherFoo XClass. Is XJavaDoc only not searching
> for classes
> >that are extended by an outer class?
> >
> >(I'm using the XJavaDoc information in a doclet subtask, if that matters)
> >
> >thanks,
> >-Tom
> >
> >
> XJavaDoc/XDoclet will only figure out the inheritance hierarchy for
> binary classes if you tell it where your binary classes are. The way to
> do that is to include whatever binary classes you want to inspect on the
> classpath you use to define the XDoclet task you're using. Are you doing
> that?
>
> Aslak
>