2017-10-10 12:05 GMT+02:00 Karl Pauls <[email protected]>:
> On Tue, Oct 10, 2017 at 9:35 AM, Guillaume Nodet <[email protected]>
> wrote:
> > 2017-10-07 18:30 GMT+02:00 Neil Bartlett (Paremus) <
> > [email protected]>:
> >
> >> 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.
>
> Are you saying that you don't see the benefit of creating another
> format (.bar files) and would rather see this contribution use the
> existing .kar format as a delivery mechanism or are you saying that
> you don't see the point at all and people should rather use Karaf
> features to begin with?
>
For sure, karaf users won't benefit from this project. I'm not implying
there isn't any value in this project of course, but I'm not sure there is
any benefit in using it if you compare it to karaf features.
The BAR format, as I understand it, could easily be handled by the karaf
features service, as it's a small subset of what it does. Some decision
can be questioned too: I don't see the benefit of using the repository xml
format to describe resources, as it leads to information duplication
(between the repository and the manifest or the embedded resources). Such
duplication means additional tooling to maintain it, which imho is
unnecessary.
So in short, karaf already supports the use case with a slightly different
archive format. The feature would look like:
<feature name="the-feature-to-install">
<requirement>the-requirement</requirement>
...
</feature>
I must confess the features service is slightly different than the
mechanism outlined here when installing the application. The karaf service
considers the whole OSGi runtime when installing application, so that you
can actually do an upgrade of any set of features. The whole wiring is
computed according to the various constraints and compared to the current
wiring and a set of ordered steps to get to the desired state is computed
and applied (orderly stop, uninstall, install, config installation,
resolution, start). It's worth noting than the computed wiring is enforced
when the bundles are resolved.
The benefit of this mechanism is that it can handle features upgrade very
easily, as you just need to change the input requirement with a newer
version of a given feature.
> Regardless (and please forgive my ignorance ), can Karaf features/kar
> archives be installed/managed using fileinstall (and if not, is that
> because they are tied to karaf or could there be a fileinstall plugin
> that would work similar to what is proposed here using .kar files)?
>
There's a plugin for fileinstall in Karaf to deploy KAR archives. Given
it's tied to the KAR format, it makes more sense to have it along the kar
related code rather than the fileinstall code. Karaf also contains other
file install deployers for blueprint, spring, plain karaf features xml and
auto-wrapped bundles.
Anyway, that won't be the first time there's some kind of duplication in
the OSGi land... Felix has 2 http providers, Karaf defaults to using the
one provide by Pax-Web. It's not a problem... I just don't foresee any
involvment from Karaf users...
Guillaume
>
> regards,
>
> Karl
>
> >> 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
>
>
>
> --
> Karl Pauls
> [email protected]
>
--
------------------------
Guillaume Nodet
