Hi,

> > IMHO this a big problem with xjavadoc, and we have to kill it
completely.
> > I find it useful to put the generated src dir in the fileset of
> > ejbdoclet so
> > that the "qualify" will work.  But this does not work at the first
build.
> > So I build twice.
> > I don't think your trick is better because some IDEs replace 10 single
> > import's into 1 package import automatically so the problem will
> > come back.
> > Users will complain,...
> > Not good.
> > Why not WARN the user when a class can not be qualified.  Aslak :
> > what does
> > happen if a class can not be qualified ?  I think it is
> > considerred as being
> > with no package.
>
> Correct. Currently, if xjavadoc can't qualify a class, an instance of
> UnknownClass without the package name is created. Consider
>
> package foo;
> class Bar {
>    // this is a class that will be generated into the same package ("foo")
>    private Zap;
> }
>
> IMHO we should instantiate an UnknownClass("foo.Zap") here instead of
> UnknownClass("Zap"). Nobody uses classes in the default package scope, and
> there are no import xxx.* statements, so "foo.Zap" is a fair assumption.
>
> Then consider:
>
> package foo;
> import bob.*;
> class Bar {
>    // this is a class that will be generated into the "bob" package
>    private Zap;
> }
>
> Here there *are* import xxx.* statements, so it's impossible for xjavadoc
to
> resolve Zap.
> We could warn OR throw an exception here. The message should say something
> nicely verbose like:
> "The Zap class could be in the following packages: [foo,bob], but xjavadoc
> can't decide since there is no qualified import for Zap, and Zap is not
> found on the classpath (perhaps it's a class that doesn't exist yet?).
> Please include an import statement for Zap using its fully qualified
name".
>
> Whether xjavadoc should warn or throw an exception can be decided based on
a
> system property: xjavadoc.class.qualify=WARN|EXCEPTION where EXCEPTION is
> the default.
>
> Waddaya think?
>

I agree.
I think WARN is the only possible option.
If you throw an Exception on :

import interfaces.*;
class Bar{
   private ZapData d;
}

import interfaces.*;
class Zap{
   private BarData d;
}

it will never complete ;)
For this example, I can not see how we can avoid running xdoclet twice.
In fact this is not needed every time, I find it needed in ValueObject and
the getBeanClassFromInterfaceName() where the interface name is a xdoclet
generated one.  Again having to explain that to the "users" is impossble.
To summarize then : xjavadoc WARN its "client".  Its "client" is XDoclet,
XDoclet report the error AND flag itself to be run again.  If it runs a
second time and still have Warning from xjavadoc then there is a problem and
a exception must be reported.
The Warning could be done using a listener ?  In XDocletMain we register for
"qualifyException" ?

Vincent (1/8 finalist)




_______________________________________________________________

Don't miss the 2002 Sprint PCS Application Developer's Conference
August 25-28 in Las Vegas - 
http://devcon.sprintpcs.com/adp/index.cfm?source=osdntextlink

_______________________________________________
Xdoclet-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/xdoclet-devel

Reply via email to