Sebastien,
We would like to enable a binary Tuscany distribution to run under OSGi. I am not sure of the level of granularity at which a bundle-ized Tuscany makes sense in terms of providing modularity and versioning using OSGi. But I would like to make sure that the bundles from the list below can be run in some form under OSGi. The big difference between packaging for OSGi and standard jars (apart from the additional entries in the manifest) is that OSGi bundle classpath can only refer to entries inside the bundle, while standard Jar classpath can only refer to jars outside the jar file without a customized classloader. I currently have Tuscany loaded into OSGi in two different ways. The first is a small list of large bundles (all 3rd party jars are grouped together), which are explicitly installed by an application that uses Tuscany. And the second is a large list of small bundles (each 3rd party jar is retained as a single bundle), loaded using OSGi bundle repository (OBR). Tuscany runtime and the required Tuscany extensions are installed by the application, the 3rd party jars are automatically installed by OBR. I am not sure how big each of the bundles you have listed below will be, and also what the relative size of the samples would be compared to the bundle itself. But I imagine that the easiest way to bundle these for OSGi would be to create each of these as a single OSGi bundle. I would like to add META-INF/MANIFEST.MF with OSGi import/export headers and an OSGi Bundle-ClassPath to the zip/jar file corresponding to the bundle. This is to enable a very coarsely grained set of bundles that can be easily installed by an OSGi application. The additional manifest file will not impact non-OSGi applications. By default, Tuscany will be run without OSGi, and the zip file corresponding to the bundle will need to be unzipped first (no change). To run Tuscany under OSGi, the zip file can be installed directly into OSGi. I would also like to enable finer grained OSGi bundles which can be installed using OBR. For the all-in-one bundle, could we have OSGi manifest entries inserted into each of the jar files including Tuscany modules and 3rd party jars, so that the jars can be installed independently into OSGi? But this only makes sense if we can have separate jars for the Tuscany extensions, rather than a combined tuscany-all.jar (otherwise OBR will install all the 3rd party bundles when tuscany-all is installed). The base Tuscany runtime could either be a single jar, or with some more fixes for classloading, it could be multiple jars based on the maven modules. Again, the OSGi manifest entries will not impact non-OSGi Tuscany. The splitting of Tuscany jars also shouldn't have any impact since tuscany-sca-manifest.jarcan just point to the longer list of Tuscany jars instead of tuscany-all. The third alternative is to have a separate set of jars, specifically targetted for OSGi-based Tuscany, which would be somewhere in between the coarsely grained first option and too finely grained second one. Rather than provide this as part of the binary distribution, this could be an optional build with the source distribution. Suggestions? Thank you... Regards, Rajini On 11/19/07, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote: > > [snip] > Makes sense to me, I'd suggest the following packages: > - base SCA runtime (assembly, policy fwk, impl-java) > - web services package (ws binding + related databindings) > - web 2.0 package (json, dwr, widget, atom, scripting) > - data integration (impl-data, openjpa) > - business process integration (bpel, xquery) > - jee integration (ejb, jms, rmi) > - spring + osgi integration (spring, osgi) > - all-in-one, for people who don't have time to solve puzzles. > > Perhaps group web services and web 2.0 together, I'm not sure. > > Also I'm not sure about where to put policies like security, > reliability, transactions. > > Thoughts? > > -- > Jean-Sebastien > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
