On 2002.11.19 20:56:33 -0500 Aslak Hellesøy wrote:
>
>
> > -----Original Message-----
> > From: [EMAIL PROTECTED]
> > [mailto:[EMAIL PROTECTED]]On Behalf Of David
> > Jencks
> > Sent: 20. november 2002 02:25
> > To: xdoclet-devel
> > Subject: [Xdoclet-devel] Big problems with 1.2 cvs version.
> >
> >
> > I'm finding a bunch of very broken behavior in the 1.2 cvs version:
> >
> > --Package level classes in the same file as a public class break
> xjavadoc
> > parsing (I wrote a sample to break the build to demonstrate this, but
> no
> > one has looked into it, except to remove the sample)
> >
>
> I've updated XJD-8 with a comment. I removed the sample that broke the
> build
> so we could get a clean build of the samples. That's pretty important. It
> would have been better to attach a file to the bug itself.
I guess you are correct about that.
>
> > --Classes are not always imported in generated code, even when imported
> as
> > a fully qualified class name in the source file. (found with apparently
> > random classes with the jdo templates and jmx templates).
> >
>
> 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.
>
> > I've discovered both these problems when I update a projects copy of
> > xdoclet to a cvs version. In both cases i've had to also add
> > commons-collection to the classpath. In both cases previously
>
> XDoclet has been using commons-collections for a long time. You must have
> be
> upgrading from a really old XDoclet version since it's not using it.
> Don't
> remember when we started using commons-collections, but it is at least 6
> month back I think.
>
> > working code
> > generation now fails. I find that I suspect that commons-collection
> is
> > the cause of these problems.
> >
> > I'd really appreciate someone who is familiar with xjavadoc and the
> code
> > that finds a fully qualified class name looking into these problems, or
> at
> > least guessing where the problem might be.
> >
>
> I didn't quite grasp what your problem is. Do you have an example (code)
> ?
>
> The code that finds FQCN is in
> xjavadoc.SourceClass.qualify(java.lang.String).
While I agree that commons-collection-2.0 has been in cvs for 5 months, it
was not previously needed to run xdoclet in jboss or the other (commercial)
project I experienced these problems in. In both cases I has to add
commons-collection to the build classpath. The xdoclet versions were
previously from Sept 16 2002 and Oct 2 2002 built from cvs.
I am well aware of the change from copying all imports, and both projects
were using xdoclet versions from after that change. I am finding that
seemingly random classes that are imported individually in the source are
not being expressed in the generated source as fqcn. Which class is not
fully qualified does seem to be repeatable.
The problem with fqcn occurred with a fresh checkout today of jboss head
(cvs co jboss-head) while building the server module. The problems occur
in several files, but only when the entire fileset is processed at once.
If files are processed one at a time the interface seems to be generated
correctly. The non-qualified class is javax.management.ObjectName.
An example signature that was not correctly converted is:
public ObjectName getTransactionManagerService()
{
...
}
The simplest way to reproduce this is probably to check out jboss, replace
the copy of xdoclet in thirdparty/xdoclet-xdoclet/lib with one just built
from cvs, and atttempt to compile the server module.
thanks
david jencks
>
> > Thanks
> > david jencks
> >
>
> HTH,
> Aslak
>
> >
> > -------------------------------------------------------
> > This sf.net email is sponsored by: To learn the basics of securing
> > your web site with SSL, click here to get a FREE TRIAL of a Thawte
> > Server Certificate: http://www.gothawte.com/rd524.html
> > _______________________________________________
> > Xdoclet-devel mailing list
> > [EMAIL PROTECTED]
> > https://lists.sourceforge.net/lists/listinfo/xdoclet-devel
>
>
>
>
-------------------------------------------------------
This sf.net email is sponsored by: To learn the basics of securing
your web site with SSL, click here to get a FREE TRIAL of a Thawte
Server Certificate: http://www.gothawte.com/rd524.html
_______________________________________________
Xdoclet-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/xdoclet-devel
