Mailing-List: contact dev-help@felix.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@felix.apache.org
MIME-Version: 1.0
In-Reply-To: <CAMm6HcD2DHzksyQi0wwvVhLz9k=vie0za8R-cf3TvQG=RURCpw@mail.gmail.com>
References: <9F2D9F9C-0C17-4554-8D86-CC48DFF09C4F@paremus.com>
 <CAMm6HcAKu391xkLBqRzWJmeurjo_YEckF9AXT4tEGcWndM=g6Q@mail.gmail.com> <CAMm6HcD2DHzksyQi0wwvVhLz9k=vie0za8R-cf3TvQG=RURCpw@mail.gmail.com>
From: Raymond Auge <raymond.auge@liferay.com>
Date: Sun, 8 Oct 2017 10:11:15 +0200
Message-ID: <CAMm6HcB56Bm=C85Ey_YMuEZymi==CdUtO7S5dqC7u7fNEFtfCw@mail.gmail.com>
Subject: Re: [DISCUSS] Contribution of Bundle ARchive (BAR) installer
To: Apache Felix Developer List <dev@felix.apache.org>
Content-Type: multipart/alternative; boundary="f403043ef16449d512055b049e0f"
archived-at: Sun, 08 Oct 2017 08:11:24 -0000

--f403043ef16449d512055b049e0f
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

I would support this as @Liferay has implemented pretty much the same
thing, used by our marketplace, called LPKGs (you can guess what that might
mean).

I'll point out the common functionality inline in support of your use case.

On Oct 7, 2017 6:30 PM, "Neil Bartlett (Paremus)" <neil.bartlett@paremus.co=
m>
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 =E2=80=94 an
implementation of the ArtifactInstaller service =E2=80=94 which handles Bun=
dle
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


LPKGs do this.

, or optionally external bundles.


Nice! This would be useful.

> 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.


We handle this effectively by enforcing that the index resolves against the
current framework, but this would be nice for either augments-style
behaviour or to support external resolution when BAR is referenced in an R5
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.


Exactly what lpkg does.

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.


Do you mean the referenced bundles or the BAR? If the bundles, how are they
reached by the agent? Does it kind of become a repository visible to a
repository service? What lpkg does is install and start (if not already
done) all referenced bundles by default which we feel is the most common
user expectation. Could this be a BAR feature configuration or flag?

> 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.


Does this mean that if the BAR itself is uninstalled that its referenced
bundles are uninstalled at once, unless referenced by another BAR?


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!


2. Eclipse and Karaf both have a similar concept of =E2=80=9Cfeatures=E2=80=
=9D, 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.


Agreed and agreed!


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 =E2=80=9Cregion=E2=80=9D of the target OSGi framework. Thi=
s 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.


Agreement, much WOW!


All sources are already Apache licensed, and were originally developed for
the Open Security Controller project (https://www.
opensecuritycontroller.org/ <https://www.opensecuritycontroller.org/>).


I just have one single use case that I'm not clear is covered (thought it
may be implied or not mentioned):

Is there a way to blacklist a particular referenced bundle such that it's
capabilities can be satisfied by some other bundle not previously known to
the bar?

We've frequently observed that in order to support some maintenance
scenarios we have to have more strict control of what gets installed
particular when providing security and/or bug fixes.

- Ray

--f403043ef16449d512055b049e0f--