Hitachi Vantara Pentaho Community Wiki

Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Migrated to Confluence 4.0

...

You can read about the steps taken to in 5.0 and 5.1 which set the stage for this migration here:
Platform enhancements in 5.0 and 5.1

...

6.

...

0 and Beyond -the next steps

The goal for 5.2 is to be able to migrate PlatformPlugins to Bundles. Several Jira cases have been created to encapsulate the work to be done in 56.20

BISERVER-11539 - Support the ability to provide Platform Plugins from OSGI
Our home-grown plugin system is limiting our ability to deliver compelling product…product

BISERVER-11540 - Deprecate the IPluginManager as a Service Locator
Have the PluginManager register objects with PentahoSystem instead so we have a single point for service location.

BISERVER-11541 - IPluginResourceLoader needs to be modified to work with resources provided by OSGI Bundles
The ResourceLoader api is separate from PlatformPlugins and The IPluginManager but one that needs to be made to work with OSGI Bundles.

[MARKET-151 - The Marketplace needs to be updated to work with OSGI Bundle plugins|http://jira.pentaho.com/browse/MARKET-

BISERVER-11542 - Sample OSGI Bundles need to be written demonstrating PlatformPlugin-like behavior

BISERVER-11543 - A Type-Tracking system needs to be added to the Pentaho Platform API
As the new system allows PlatformPlugins and OSGI Bundles to be de/registered at runtime, we need a way to notify other areas of the system of the events.

BISERVER-11544 - PentahoSystem's AggregateObjectFactory needs to be updated to cache query results Currently PentahoSystem.getXXX calls are not cached and query the underlying ObjectFactory implementations with every call. This can become extremely inefficient as the System grows.

BISERVER-11545 - The Pentaho Spring Extensions need to be updated for Spring 3.2.5 so they can be used within OSGI Bundle Blueprint files

7.0 Goals

Once we have the ability for plugins migrate the OSGI, the next step is to move the "core" code into OSGI as well. This involves moving the OSGI container from an isolated embedded space to become the top-level container of the system. This migration is easier than it sounds. The "core" code left after 5.2 is all contained in the "pentaho" WAR. OSGI supports the deployment of WARs as OSGI bundles. The entire pentaho WAR will become one large WAB (Web Application Bundle). From there the work of separating out parts to their own distinct bundles can begin.

Also in 6.0 is the switch to the OSGI Service Registry away from PentahoSystem. All IPentahoObjectFactories in the 6.0 timeframe will be updated to register with the OSGI ServiceRegistry. Once done the PentahoSystem.getXXX() calls can be migrated away from our code to simply call into OSGI. Once this is done we can start the process of deprecating the Pentaho-Specific APIs and transition to plain OSGI.

7.0 Architecture:

Image Added

Continue on to Platform enhancements in 5.0 and 5.1