----- Original Message -----
From: "Vincent Harcq" <[EMAIL PROTECTED]>
Date: Friday, June 14, 2002 11:15 am
Subject: Re: [Xdoclet-devel] CVS update:
xdoclet/samples/src/java/test/ejb CustomerBean.java
> 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
> xjavadocto
> > 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
> qualifiedname".
> >
> > 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;
> }
>
import interfaces.ZapData;
class Bar{
private ZapData d;
}
import interfaces.BarData;
class Zap{
private BarData d;
}
Would solve the problem. I know some IDEs want to convert to * if there
are more than N import from the same package, but this behaviour should
be able to turn off, or it's a lousy IDE.
-And here is a new idea:
One option could be to pass a list of package names to xjavadoc during
initialisation. Then xjavadoc will use the first package name in the
list that matches any import xxx.* statements. For your case you'd do
something like.
<ejbdoclet guesspackages="yadayada,interfaces" ... />
The first package in this list that is also imported in the class will
be used to qualify other unknown classes. If none of the guesspackages
are among the imported packages, then qualify to the same package as
the class itself.
Can be implemented in XJavaDocTask.setGuesspackages(String) and
SourceClass.qualify(String)
> 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
> xdocletgenerated 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" ?
>
Sure, we can do this, but I think it's over-complicating things. I
prefer telling the user what to do (import classes and not packages)
and then exiting with an exception. If we try to make XDoclet too
smart, it will take over the world and we'll have a nuclear war.
> Vincent (1/8 finalist)
>
Aslak (not qualified())
>
>
>
_______________________________________________________________
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
