So you import a class explicitly but the generated class uses the unqualified name of that class? Maybe that class is not in the classpath of ejbdoclet taskdef? If it's from a third party jar. Otherwise seems to be a bug.
Ara. --- Matthias Bohlen <[EMAIL PROTECTED]> wrote: > Hi Ara, > > you almost convinced me but puzzled me in your last paragraph: > > > Solution: > > Help XDoclet! Either use full qualified names (com.blabla.AClass) > or > > import it explicitly (import com.blabla.AClass;//note: com.blabla.* > > won't do it). > > There *was* an explicit import statement but the XDoclet-generated > local > interface file was not compilable because XDoclet did not copy the > import > statement from the bean class source to the local interface source. > > How can I import something correctly? > > Cheers... > Matthias > > > -----Original Message----- > > From: Ara Abrahamian [mailto:[EMAIL PROTECTED]] > > Sent: Sunday, October 13, 2002 9:55 PM > > To: 'Matthias Bohlen'; [EMAIL PROTECTED] > > Subject: RE: [Xdoclet-user] Always fully qualified class names? > > > > > > > today, I tried to switch from XDoclet 1.1.2 to 1.2.0-beta1. What > > > startled me: My "import" statements are NOT copied from the > > bean class > > > *.java to the generated local interface *.java file so that > > this file > > > does not compile because a method signature references an > imported > > > class. This is a difference to XDoclet 1.1.2. > > > > > > Question: Does this mean that I have to write fully qualified > class > > > names with an average of 60 characters all over my bean class > source > > > code? If the answer is yes, I say: What a hassle! What an > > inconvenience! > > > > > > Can somebody clarify this for me? > > > > Yes! No imports in 1.2 and the reason is XDoclet has to work with > full > > qualified names. > > > > An example: > > You use <entitycmp/> which generates a subclass for the cmp bean. > With > > imports xdoclet should copy the imports of the bean impl class and > all > > of its superclasses and implemented interfaces to the > > subclassed class, > > because the subclass overrides get/set methods of all its > superclasses > > to track modification and for VO/DO too. That means a huge ugly > import > > statement, and guess what, it's bad too. Why? Because then you > can't > > create a pure interfaces jar for a swing client for example, > imports > > from the implementation class is also there in the remote > interface! > > > > Solution: > > Help XDoclet! Either use full qualified names (com.blabla.AClass) > or > > import it explicitly (import com.blabla.AClass;//note: com.blabla.* > > won't do it). > > > > Ara. > > Weblog: http://www.freeroller.net/page/ara_e > > > > > > __________________________________________________ Do you Yahoo!? Faith Hill - Exclusive Performances, Videos & More http://faith.yahoo.com ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ Xdoclet-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/xdoclet-user
