Thanks Ray. Replies inline below. > On 8 Oct 2017, at 09:11, Raymond Auge <raymond.a...@liferay.com> wrote: > > 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.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 > > > 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.
We need the Require-Capability/-Bundle headers because resolving always involves two inputs: an index and a set of requirements. Initially we only supported Require-Capability, but we added Require-Bundle as a convenience because most users will want to require bundles most of the time, and the syntax for Require-Capability is fiddly. Now the input to the resolver is the union of Require-Bundle and Require-Capability; at least one of these must be present. > > > 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? The referenced bundles are installed — the BAR itself cannot be installed into an OSGi Framework because it is not a bundle. The index of the BAR is instantiated as a repository, but that repository object exists only briefly. The index contains URI references to the actual bundles. Where those URIs are relative, we resolve them relative to the index location within the BAR file. They are physically loaded using the “jar:” URI scheme which is supported by the Java platform. The index can also contain absolute URIs, which is how we support external bundles. The BAR Installer does not immediately install the bundles because in Open Security Controller we wanted to have a two-stage process where the user first uploads a “plugin” (the BAR file) into the monitored folder and sees in the UI that it is valid, and then manually triggers the actual installation via a button. The user can also uninstall the BAR contents without physically deleting the BAR file from the monitored directory. If an application wants a simpler flow then it can implement the InstallableUnitListener service and immediately call install() on units entering the RESOLVED state… this is approx 15 lines of code. > >> 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? Yes. > > > 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 “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. > > > 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 “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. > > > Agreement, much WOW! > > > All sources are already Apache licensed, and were originally developed for > the Open Security Controller project (https://www <https://www/>. > opensecuritycontroller.org/ <http://opensecuritycontroller.org/> > <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 do not support blacklisting at present, but this could be added. In our use cases it was easy enough to exclude certain bundles by not including them in the BAR index, but if assembling the index using Maven transitive dependencies I can see how you could sometimes have difficulty excluding specific dependencies. > > 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
