> On 7 Oct 2017, at 18:30, Neil Bartlett (Paremus) <neil.bartl...@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 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. > > 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. WDYT? -- 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 https://www.luminis.eu KvK (CoC) 09 16 28 93 BTW (VAT) NL8170.94.441.B.01
signature.asc
Description: Message signed with OpenPGP
