On 5/5/08, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote: > Rajini Sivaram wrote: > > > > > At the moment, I am creating a single virtual 3rd party bundle. For the > > longer term, if there are use-cases where different Tuscany extensions > > require different versions of 3rd party libs, we may want to split this > > into > > multiple virtual bundles. > > > > > How about having one virtual bundle per 3rd party JAR? > > Isn't that what we'll need to really leverage the OSGi classloader > isolation and versioning capabilities? > > Isn't that also what these 3rd parties will do once they OSGi-enable their > own JARs?
Yes, you are absolutely right. I started with the assumption that to leverage versioning of 3rd party libraries, we will need explicit versioned import/export statements in all 3rd party bundles. I preferred to generate these offline during the build process, and the generated manifest file is added to tuscany-sca-manifest.jar (not as a manifest, but as a plain resource). The code which generates virtual bundles at the moment looks for .mf files corresponding to the 3rd party jars. If a file (eg. stax-api-1.0-2.mf) is found in tuscany-sca-manifest.jar, a separate virtual bundle is generated for it (ie, stax-api-1.0-2 becomes a separate bundle). All the remaining jars without specific .mf files and bundled together into a single virtual bundle. At the moment, the build generates only a single combined manifest entry, and hence a single virtual bundle is used. This is mainly because I couldn't figure out an easy way to generate separate manifest entries using a single pom and maven-bundle-plugin (but then my knowledge of maven is very very limited). In the short term, just sorting out the build to generate individual manifest entries for 3rd party jars will give us something to explore versioning of 3rd party libs, and side-by-side execution of these in Tuscany. For the longer term, we need to look at the best way to generate manifest files for 3rd party libs. Should we for instance do this at runtime, rather than build-time? Could we generate simpler export/dynamic-import statements at runtime without using maven-bundle-plugin, and still support versioning of third party libs? What is the performance impact of individual virtual bundles on classloading? At the moment, we haven't done any analysis of who requires what on TCCL. So all 200 bundles will be on TCCL (making TCCL based classloading rather inefficient). > -- > Jean-Sebastien > -- Thank you... Regards, Rajini
