290 likes | 504 Views
Overview. Motivations. Provide modularity for Tuscany to formalize/enforce the SPI contracts and minimize the package dependencies across modules Enable Tuscany to work with OSGi environment such as JEE application servers, Eclipse RCP or Spring DM Provide versioning and isolation so that Tuscany
E N D
1. OSGi Enablement for Tuscany Raymond Feng
2. Overview
3. Motivations Provide modularity for Tuscany to formalize/enforce the SPI contracts and minimize the package dependencies across modules
Enable Tuscany to work with OSGi environment such as JEE application servers, Eclipse RCP or Spring DM
Provide versioning and isolation so that Tuscany extensions can depend on different versions of the same library
Provide lifecycle management for extensions: install/uninstall/start/stop a module
4. Objectives Tuscany runtime will be able to run in both non-OSGi and OSGi environment
No OSGi APIs should be used for non-OSGi specific modules
Build a consistent OSGi story to facilitate developing, building, launching, running and testing Tuscany
Makes developers’ life a bit easier to work with OSGi
5. What problems do we try to solve? Turning Tuscany modules into OSGi bundles
Turning 3rd party dependencies into OSGi bundles
Developing, building, launching, running and testing with OSGi
Producing distributions that are compatible with the OSGi bundle structure in an efficient way (in one-two minutes)
6. Turning Tuscany modules into OSGi bundles
7. Creating bundles for Tuscany modules Modularize Tuscany after the maven modules
One OSGi bundle per maven module
Be consistent for build, packaging and runtime
Much easier to aggregating than decomposing
Developers are responsible for authoring and maintaining MANIFEST.MF (instead of MF generation tools)
Tooling friendly
Developers pay more attentions to the dependencies
8. Things to consider to create an OSGi bundle for a module Add META-INF/MANIFEST.MF (don’t stop here …)
Clean up module dependencies and package visibilities
Prepare for code changes
Service Discovery
ClassLoading
9. Rules of thumb Identify the absolutely necessary SPI packages that need to be exported
Don't try to export everything
For model modules, try to only export the package that contains the interfaces
Try not to export any package from the xxx-runtime moudles
Any classes that can be accessed via the ExtensionPointRegistry using interfaces should not be exported
Only import other packages when it's needed
For example, we used to have a lot of modules pull in assembly for just a constant for the SCA namespace
Avoid DynamicImport-Package=*
Avoid Require-Bundle
Do not export "private" packages as a workaround or hack which can fail the "clean SPI". Refactor things into SPIs if necessary
10. Granularity Discussion 180+ bundles cumbersome
Multiple bundles required to enable one capability
Much debate about right level of granularity (flexibility vs. usability)
Some opinions
Fine-grained bundles suitable for developer view
Features/Profiles used to “group” bundles to provide a user view
Inspired by Eclipse Features
11. Dealing with 3rd party jars
12. Handling 3rd party jars We have to live with the reality:
Many 3rd party jars are not OSGi bundles. No repo is available to get all converted bundles
We need to convert them (build time, run time)
Some of the 3rd party bundles are broken (w/ bogus MF)
We need to fix them (replacing the MF)
More and more 3rd party jars are upgraded to be OSGi bundles
We should be able to incrementally consume 3rd party jars as OSGi bundles
13. Converting 3rd party jars to OSGi bundles A folder bundle is created to represent a 3rd party jar The folder structure looks like: jaxb-impl-2.1.12 META-INF MANIFEST.MF jaxb-impl-2.1.12.jar It is non-invasive and flexible The original jar is not changed (avoid legal, signature issues) Multiple jars can be easily aggregated (control the bundle granularity) The MANIFEST.MF can be easily customized