1 / 29

OSGi Enablement for Tuscany

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

faraji
Télécharger la présentation

OSGi Enablement for Tuscany

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

    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

More Related