2017-10-10 13:00 GMT+02:00 Neil Bartlett (Paremus) <
neil.bartl...@paremus.com>:

>
> > On 10 Oct 2017, at 08:35, Guillaume Nodet <gno...@apache.org> wrote:
> >
> > 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.
>
>
> Hi Guillaume,
>
> There may indeed be similarities between this contribution and the Karaf
> feature/KAR installer. However our code is intended to be used standalone,
> including in embedded scenarios where the Karaf platform is quite
> heavyweight. It’s not clear to me that the KAR installer can be used
> independently of the rest of the Karaf platform, or at least I have not
> been able to find any documentation on how to do that.
>

I haven't seen any requests for that.  Karaf 4 has seen a lot of
improvements, so there's absolutely no bundles that are required anymore.
Usually people want to leverage karaf features at runtime, so you need to
install a few bundles: pax-logging, the feature service, config admin, file
install.  This usual minimal set of bundles can be seen at the following
location:

https://github.com/apache/karaf/blob/master/assemblies/features/framework/src/main/feature/feature.xml#L24-L38
Typical karaf additions such as the console, web service, blueprint,
transaction manager, cdi, ... can be deployed at runtime using the console
or JMX.
That said, users also have the ability to use features and kars to build
their own runtime at build time.  If you do so and don't want to leverage
the OSGi dynamic nature at runtime (think about docker for example), you
can leverage the karaf features to compute a set of bundles at build time
(and make sure everything can be resovled correctly), and not deploy any of
these bundles at runtime.
Anyway, Karaf 4 is much more lightweight and versatile than previous Karaf
versions.


>
> Also as far as I’m aware, Apache rules do not prevent similar
> functionality from appearing under different projects.
>

Yeah, sure.


>
> Thanks,
> Neil
>
>
> >
> >
> >>
> >> 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
>
>


-- 
------------------------
Guillaume Nodet

Reply via email to