Hello Jan, > On 9 Oct 2017, at 09:56, Jan Willem Janssen <janwillem.jans...@luminis.eu> > wrote: > >> >> On 7 Oct 2017, at 18:30, Neil Bartlett (Paremus) <neil.bartl...@paremus.com >> <mailto: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/> >> <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.
Yes that would be a relatively simple refactoring. I suggest looking at this kind of change after the initial contribution is in the Apache incubator. Thanks for your interest, Neil > > 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 <https://www.luminis.eu/> > > KvK (CoC) 09 16 28 93 > BTW (VAT) NL8170.94.441.B.01
signature.asc
Description: Message signed with OpenPGP using GPGMail
