I'm having a hard time deploying an ear. It contains two ejb modules, and a library folder containing a jar file with annotated entities. These entities need to be shared over several persistence modules in several different ears, and for my reasons, it doesn't make a lot of sense to package them up into an ejb that is shared on it's own. Basically, the entities don't change, but the business logic governing them does, depending on the context.
ts-3.0 ts-3.0/common-ejb-3.0.jar ts-3.0/lib ts-3.0/lib/common-jar-3.0.jar ts-3.0/lib/jgroups-2.9.0.GA.jar ts-3.0/META-INF ts-3.0/META-INF/application.xml ts-3.0/ts-ejb-3.0.jar I was going to use <jar-file> but it appears that all ear library files are processed for annotations. Perhaps only <class> tags are necessary. However, the processing of the library throws an issue at AbstractCFMetaDataFactory (line 706 in 3.0b1). The URL that is created for the library file can not be found. I have something like: jar:bundleentry://475.fwk2002021820/../lib/common-jar.jar!/ Where in my file system, I have: ./var/cache/org.eclipse.osgi/bundles/475/1/.cp/common-ejb-3.0.jar ./var/cache/org.eclipse.osgi/bundles/475/1/.cp/lib/common-jar-3.0.jar ./var/cache/org.eclipse.osgi/bundles/475/1/.cp/lib/jgroups-2.9.0.GA.jar ./var/cache/org.eclipse.osgi/bundles/475/1/.cp/ts-ejb-3.0.jar I know the ".." was from a previous bug fix, where paths are computed from the root of the EJB, and not the EAR, making the reference. However, it seems as though that convention does not translate to how jars are processed and exploded under the bundle on the filesystem. If I need additional meta-data, or if there's additional documentation (an example build demonstrating the ability), I'm all ears. Otherwise, I'll deal with this from a dev perspective. -jjk
