ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Conor MacNeill <>
Subject Re: Some thoughts about ejbjar
Date Mon, 17 Sep 2001 12:33:13 GMT
Holger Engels wrote:

> there are some issues with the current implementation:
> 1) dependent classes aren't found
> 2) client jars aren't supported
> 3) different DeploymentTools cannot append to the _same_ jar. This means,
> that it is not possible to generate a jar, that works on more than one
> appserver (is this correct?)
> 4) the naming convention <component-name>-* is not applied to
> manifest-files.
> 5) Adding new DeploymentTools requires changes to the EjbJar class
> I'd propose the following:
> 1) use BCEL to discover _all_ dependent classes. The depend-task seems to
> not find them all. I have written a visitor for BCEL, that does find them.
> BCEL is LGPL - I think, we should use it rather than parsing class files
> ourself - IMHO it's a cool mature framework.

I'd be interested to have an example of where the depend code is not 
finding all the dependencies. I have no objection to using BCEL in 
principle although it seems BCEL could not be distributed with Ant, as 
it contains GPL code, according to their website

"Note that there is the FindPattern class distributed together with the 
BCEL that uses the gnu.regexp package, which itself is protected by the 
GPL. Thus this part of the distribution can not be redistributed using a 
different license." Overall I'm not sure how they distribute an LGPL 
package containing GPL code.

> 2) find classes that depend on home / remote / pk classes. Add server
> specific classes and stubs, if required (not for jboss).
> 3) allow destdir-attribute in ejbjar-tag. Pack one jar, that contains all
> classes / files of DeploymentTools

I'm not sure how easy this will be. My original vision was to allow one 
<ejbjar> task to generate separate jars for each appserver. I wonder if 
separate appserver jars may collide. If, in the end you are just 
combining the result jars of multiple tools, why not let the user do that.

> 4) just do it - fetch manifest-files from the directories, where the
> deployment descriptors are found

OK. I think manifest files are more important now than they used to be. 
As far as I can tell with weblogic, ejbc just obliterated it anyway. 
That has probably changed with 6.1, but I haven't tried that yet.

> 5) use naming convention .. the problem is the xml-parser, that does not
> allow tags without setter- / adder-correspondents, right?

Not the parser as such. I did have a solution for this which was for the 
introspection helper to forward any requests for nested element creation 
to the task itself if the reflection based mechanisms failed. This would 
have allowed property file based config of the supported appservers or 
some similarly dynamic mechanism. It was vetoed by Peter.

> Open issues:
> 1) there are dependant classes, that cannot be found at all.
> Implementations of interfaces, that aren't explicitely used and
> Resource-Files. 'includefiles' of filesets, that are discovered by the
> same naming convention like deploymnet descriptors / manifests would help.

Yes, using the naming convention is possible. I'm not sure how popular 
the naming convention is though :-)

> 2) finding dependant classes should be a feature of filesets.

A special type of fileset, perhaps, but not of the plain vanilla 
fileset. When Craeg had mentioned the concept of a <dependset>, this is 
what I thought he was referring to as it was soemthing I had been 
contemplating. It may also be possible to add this to the jarring code 
and have the ejb tasks use that jarring code as the method for generic 
jar construction.

> .. we end up doing a complete redesign of the ejbjar task ..

As long as it is backward compatible, it is not a problem. So, we should 
develop some unit tests first.Lets go in small steps rather than 
changing everything at once.


View raw message