Rajini Sivaram wrote:
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.
OK, the idea of .mf looks good to me, but I can't really use
tuscany-sca-manifest.jar as it doesn't work in Eclipse, and out of
Eclipse it drags all the Tuscany JARs which I don't always need.
Could you put the .mf files in another JAR that I can use in an OSGi
environment?
At the moment, the build generates only a single combined manifest entry,
and hence a single virtual bundle is used.
I'm confused, can you point me to that single manifest entry and the
code or build that generates it?
Thanks!
--
Jean-Sebastien
