> -----Original Message-----
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]On Behalf Of Vincent
> Harcq
> Sent: 14. juni 2002 07:58
> To: [EMAIL PROTECTED]; Ara Abrahamian
> 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 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?
> Or better: restart a second generation when a qualify failed.
> Ideas ?
>
> Regards,
> Vincent
>
> ----- Original Message -----
> From: "Ara Abrahamian" <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Sent: Thursday, June 13, 2002 9:16 PM
> Subject: [Xdoclet-devel] CVS update: xdoclet/samples/src/java/test/ejb
> CustomerBean.java
>
>
> > User: ara_e_w
> > Date: 02/06/13 12:16:50
> >
> > Modified: samples/src/java/test/ejb CustomerBean.java
> > Log:
> > - MethodImpl.buildStringId() is ued for hashcode/equals, but also uses
> modifiers of the method, which is wrong, because if you override
> an abstract
> method then it thinks they are two different methods, which
> really are not,
> and that leads to problems in some of the superclass/override sensitive
> templates. I removed modifiers from the calculation.
> > - CustomerBean had missing imports, which leads to overriding code to
> fail. I also added a long description about why you should
> explicitly import
> to CustomerBean's import section.
> > - cleanup
> >
> > Revision Changes Path
> > 1.4 +26 -1
> xdoclet/samples/src/java/test/ejb/CustomerBean.java
> >
> > Index: CustomerBean.java
> > ===================================================================
> > RCS file:
> /cvsroot/xdoclet/xdoclet/samples/src/java/test/ejb/CustomerBean.java,v
> > retrieving revision 1.3
> > retrieving revision 1.4
> > diff -u -w -r1.3 -r1.4
> > --- CustomerBean.java 12 Jun 2002 09:22:46 -0000 1.3
> > +++ CustomerBean.java 13 Jun 2002 19:16:50 -0000 1.4
> > @@ -5,7 +5,32 @@
> > import javax.ejb.*;
> > import javax.naming.*;
> >
> > -import test.interfaces.*;
> > +//remember it helps xdoclet if you define the exact import statement
> > +//test.interfaces.* won't do it.
> > +//The reason is that CustomerData for example is not yet generated,
> > +//so xdoclet encounters a method which has CustomerData parameter,
> > +//tries to find its package name, but because it's not generated yet
> > +//assumes it's in current package (test.ejb). So if you then override
> > +//from this package for example, xdoclet can't figure out
> that it's the
> > +//same method (different parameter types) and that means you
> may end up
> > +//with two methods with the same syntax!
> > +//As an example you can remove these explicit imports, use
> test.interfaces.*
> > +//and see what happens. you see that the derived
> test.ejb.CustomerBMPBMP
> > +//subclass has two ejbPostCreate(CustomerNormalValue data) methods
> because
> > +//CustomerBMPBean imports CustomerNormalValue explicitly but
> CustomerBean
> > +//doesn't, so xdoclet thinks they are two different methods, not
> redundant
> > +//overriden methods. Overall the best thing you can do is define the
> parameters
> > +//in full qualified format, instead of imports, for stuff which will
> later be
> > +//autogenerated by xdoclet.
> > +import test.interfaces.Customer;
> > +import test.interfaces.CustomerData;
> > +import test.interfaces.CustomerPK;
> > +import test.interfaces.CustomerNormalValue;
> > +import test.interfaces.CustomerLightValue;
> > +import test.interfaces.ApplicationException;
> > +import test.interfaces.CustomerLightValue;
> > +import test.interfaces.AccountHome;
> > +import test.interfaces.AddressLocalHome;
> >
> > /**
> > * This is a customer bean. It is an example of how to use
> the XDoclet
> tags.
> >
> >
> >
> >
> > _______________________________________________________________
> >
> > 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
> >
>
>
> _______________________________________________________________
>
> 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
_______________________________________________________________
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
