felix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jan Willem Janssen <janwillem.jans...@luminis.eu>
Subject Re: [DISCUSS] Contribution of Bundle ARchive (BAR) installer
Date Mon, 09 Oct 2017 08:56:20 GMT

> On 7 Oct 2017, at 18:30, Neil Bartlett (Paremus) <neil.bartlett@paremus.com> wrote:
> 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
> 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
> 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.
> 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.
> All sources are already Apache licensed, and were originally developed for the Open Security
Controller project (https://www.opensecuritycontroller.org/ <https://www.opensecuritycontroller.org/>).

Nice work! I’ve glanced through the code and was wondering whether it is an idea to separate
the file-install specifics from the more generic resolver/management parts. It would allow
BARs to be installed by using different means (for example, a custom management agent) than
file install.


Met vriendelijke groeten | Kind regards

Jan Willem Janssen | Software Architect
+31 631 765 814

My world is something with Amdatu and Apache

Luminis Technologies
John F. Kennedylaan 32
7314 PS  Apeldoorn
+31 88 586 46 25


KvK (CoC) 09 16 28 93
BTW (VAT) NL8170.94.441.B.01

View raw message