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