2017-10-07 18:30 GMT+02:00 Neil Bartlett (Paremus) < neil.bartl...@paremus.com>:
> Hello Felix developers, > > I would like to initiate a contribution of external code into Apache > Felix. This code is being contributed on behalf of Intel Corporation, who > funded development. The contribution is a plugin for File Install — an > implementation of the ArtifactInstaller service — which handles Bundle > ARchive (BAR) files. This is a proposed format for an aggregate of > functionality represented as one or more OSGi bundles along with an OSGi > index. It includes use of the OSGi resolver API to check consistency and > permits overlapping resources from multiple installable units. > > A BAR file is physically a JAR file with some defined manifest headers to > control the behaviour of the installer. It must contain an OSGi index (in > the XML format specified by the Repository Service specification) and the > index can reference bundles contained within the BAR, or optionally > external bundles. Additionally the BAR manifest contains a set of > requirements (a Require-Bundle and/or Require-Capability header) that > define the root requirements to be resolved against that index. > > Dropping a BAR file into the File Install monitored directory does not > immediately install its contents. Instead a resolution process is initiated > to ensure that the contents of the BAR are complete and consistent. If that > resolution process succeeds then the BAR contents become available for > installation. The application or management agent is responsible for > triggering the actual installation. Multiple BAR files can require the same > resource transitively. We use a reference counting mechanism to ensure that > BARs with overlapping requirements can be installed concurrently, and those > resources are only uninstalled when the last BAR that references them is > uninstalled. > > This differs from existing approaches in the following ways: > > 1. The OSGi Deployment Admin specification defines a similar file format > for aggregates of bundles, but the contents of a Deployment Package cannot > overlap with previously installed Deployment Packages. This limitation > makes the specification unworkable in many practical scenarios. > Agreed, the Deployment Admin limitations just make it usually useless. > > 2. Eclipse and Karaf both have a similar concept of “features”, but these > are simply listings of bundles. The BAR Installer uses the OSGi resolver to > ensure that the contents of the BAR can actually be installed cleanly in > the current OSGi framework, and will never attempt to reinstall a bundle > that is already in use. > That's not the case anymore for Karaf since Karaf 4.0.x (2 years ago) which actually use the OSGi resolver. Karaf also provides a kar archive which is somewhat similar in that it provides karaf features file along with bundles. Karaf features and kar archives provide much more (configuration, additional files, conditional, region scoping) than what is outlined here, so I don't really see the benefit. > > 3. The OSGi Subsystem Service specification has the ability to resolve the > contents of a subsystem, but the resolved bundles are usually installed > into an isolated “region” of the target OSGi framework. This creates a lot > of complexity, and as a result the Subsystems chapter of the OSGi > specification makes for a daunting read. BARs are installed into the flat > OSGi framework without isolation, have a simpler lifecycle and are easier > for developers to reason about. > Karaf features can support regionned and/or flat systems. > > All sources are already Apache licensed, and were originally developed for > the Open Security Controller project (https://www. > opensecuritycontroller.org/ <https://www.opensecuritycontroller.org/>). > > Thank you, > Neil Bartlett -- ------------------------ Guillaume Nodet
