Page History

...

Strategy	Options	Pros	Cons	Note
Build-time conversion	Using tools (such as maven-bundle-plugin) to convert plain jars into OSGi bundles	Ready-to-use bundles for any OSGi runtime No addtional runtime overhead to convert the jars More control on how packages are imported/exported	Extra steps are required to build the bundles first and it increases the complexibilty for development testing inside an IDE such as Eclipse Two sets of jars are created Maven build uses different jars than the OSGi bunldes which are not published into maven	Maven Bundle Plugin: http://felix.apache.org/site/maven-bundle-plugin-bnd.html\\\\\\\\\\\\\\\\\\\\\\\\^{Image Modified} Felix Commons: http://felix.apache.org/site/apache-felix-commons.html Ecipse Orbit: http://www.eclipse.org/orbit/ Spring DM Repo: http://static.springframework.org/osgi/docs/1.1.1/reference/html/appendix-osgi-repo.html
	Use already-converted 3rd party bundles from Spring DM, Felix Common or Eclipse Orbit		Not all 3rd party jars are available in OSGi bundles
Runtime converstion	Before the jar is installed (BundleContext.installBundle())		Tuscany needs to install the bundles Performance impact
	Add a hook to the OSGi runtime to wrap the jar (such as			Equinox Hooks: http://wiki.eclipse.org/index.php/Adaptor_Hooks http://www.eclipsecon.org/2008/sub/attachments/Equinox_Framework_How_to_get_Hooked.pdf
Hybrid conversion	Build-time will generate the META-INF/MANIFEST.MF as a side file Runtime will wrap the 3rd party jar with the side file

...

Wiki Markup
That step is fast as it just writes a Manifest to a byte\[\] in memory, with no need to copy the JARs and re-package them, as the manifest


simply references their actual locations.

4) Bundle tuscany-extensibility-equinox contains a DynamicImport *, enabling ServiceDiscovery to access the 3rd party packages.

...

Tuscany OSGi Integration

Work Items	Status
Package Tuscany modules as OSGi bundles	Partially done. The following items remain: Share the maven bundle plugin configuration Rationalize the association of Tuscany ModuleActivator and OSGi Bundle Activator Make sure unique Bundle-SymbolicName Avoid split java packages
Package all of the 3rd party jars as an OSGi bundle	Partially done. The following items remain: Experiement one big bundle or multiple bundles Resolve inconsistency between the maven-generated the .classpath and the Bundle-ClassPath entry
Provide a SCA node launcher to run SCA application with OSGi-enabled Tuscany runtime	The launcher now works with SCA node. The following need to be supported as well: SCA Domain Manager NodeDaemon Webapp-based launcher
Support different bundle packaging and distribution schemes (jars and class folders, distribution and Eclipse workspace)
Bring up the calculator sample with Equinox Node Launcher	Done
Bring up the calculator RCP with Eclipse Equinox	Under bring-up
Use the Import/Export packages for Tuscany modules to enforce the SPI contracts, Refactor SPIs if necessary, Split a few modules into model and runtime
Change how JDK factories are discovered and instantiated	Done for the core
Rationalize and clean up the SCA contribution classloading strategy
Convert samples and itests to use the OSGi-enabled Tuscany runtime

Work Items	Status
Support packaging of SCA contributions as OSGi bundles
Support the OSGi import/export as SCA contribution import/export
Convert some samples or itests to use OSGi bundle as the SCA contributions

Work Items	Status
First step: Define a set of scenarios to better understand the resulting programming model (OSGi + SCA) Potentially implementation.osgi and Enterprise OSGi