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. 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
