Currently xdoclet head is broken in a very peculiar way: sometimes when
processing a large fileset one import will not get converted to its fqcn in
generated source, even though it is imported as a fqcn.  I have experienced
this in two projects over the last couple weeks. It does not occur when the
fileset is restricted to one file.

I can reproduce this by checking out jboss, replacing the xdoclet copy
(thirdparty/xdoclet/xdoclet/lib) with one from cvs, and trying to build the
server module.

Both projects were previously using xdoclet versions that did not copy
imports, and worked perfectly.

david jencks

On 2002.11.20 18:59:00 -0500 Andrew Stevens wrote:
> A wise old hermit known only as Marcin Gryszkalis <[EMAIL PROTECTED]> once said:
> 
> > I just compiled CVS version of xdoclet 1.2
> > and tried to test it on one of my projects
> >   - the problem is that it seems not to
> > copy import statements to generated remote interface
> > of session beans
> > (it did in 14/09/2002 1.2 build)
> >   - and I cannot compile stuff w/o imports.
> > 
> > It seems that it's not copied to any of generated files...
> > (I just checked)
> > 
> > Is there any additional tags I have to add to sources?
> 
> As Aslak just said over in xdoclet-devel:
> 
> > This has been debated many times before. The generated classes
> shouldn't
> > blindly import the same classes as the class it was generated from.
> This
> > would result in e.g. EJB home interfaces having imports of bean
> > implementations, which is bad because the impl then has to be packaged 
> > with the interfaces (on the client).
> > 
> > We took away the copy-paste import statements code several months ago. 
> > So
> > generated code shouldn't import any classes at all (except those that 
> > might be hardcoded in the template), but refer to fqcn instead.
> > 
> > I know that this might break BWC with classes that don't usw FQCN, but
> > believe me, copying the imports all over is a bad thing.
> 
> The class names that get written out into the interfaces should be 
> converted to the fully qualified form automatically; if they're not, it's
> 
> probably because xjavadoc couldn't figure out what package they supposed 
> to be in (e.g. you've been using import foo.bar.* instead of importing 
> them individually or using the FQCN).
> 
> What classes is the compiler complaining that it can't find?  Did you 
> import them explicitly in the bean class?  If you still can't get it 
> working, post a sample for us to look at.
> 
> 
> Andrew.
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: The Sourceforge Network Survey
> Take Our Survey and You Could Win a $500 Gift Certificate!
> http://ugamsolutions.com/psurvey/osdn/SourceForge/index_sourceforge.htm
> _______________________________________________
> Xdoclet-user mailing list
> [EMAIL PROTECTED]
> https://lists.sourceforge.net/lists/listinfo/xdoclet-user
> 
> 


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

Reply via email to