I understand that you are seeking a more standard way than karaf features to deploy parts of an application. Indeed subsystems look like a good way at first. Unfortunately they add a lot of complexity to a system. So almost no one uses them.
Currently there are two major ways of packaging an application: - karaf features (uses repository + + requirements under the covers). A feature repo is described in xml. The bundles from all the required features form the repository. The bundles with dependency=false form the requirements. - repository + requirements based approach like used by bnd (without features). They currently use a pom file to describe a repository + requirements in a bndrun file. So I agree it would be great to have a more standard way to package applications. I discussed with JB that we could make more explicit use of repositories for karaf features. The idea is to describe karaf features using a backing repository + required bundles for each feature. We could describe the repository for the feature in a pom and refer to it in the feature repo file. The features would then only contain the required bundles. This approach would provide a repository in pom form for all karaf features that is then also usable by bnd for packaging. So projects like aries would only need to provide one common form of feature description. Besides this there is a standardisation effort at the OSGi alliance for features. Currently the work in progress there looks more like karaf 2 featues, so it is not usable for karaf but maybe in the next iteraion a repository based approach is considered. Chritian Am Di., 27. Nov. 2018 um 21:56 Uhr schrieb Leschke, Scott < slesc...@medline.com>: > It wasn’t really a dev request per se, more of a curiosity question as to > whether something along those lines was being considered as it would seem > to make the implementations more easily consumable in a variety of OSGi > environments. My primary interest is in Karaf which is why I guess I > targeted this list. Perhaps I should have thought that through better. > > > > As for how something like that were structured, I don’t know really. I > only have passing familiarity with the Subsystem spec and that it sort of > overlaps and extends what Karaf Features do, at least to my knowledge. My > take is that a Karaf Feature commonly maps to an OSGi service spec. > implementation, even if the names don’t match exactly > > > > I readily admit that I could be grossly mistaken on that. > > > > Scott > > > > *From:* David Jencks <david.a.jen...@gmail.com> > *Sent:* Tuesday, November 27, 2018 2:08 PM > *To:* user@karaf.apache.org > *Subject:* Re: Aries > > > > I’m somewhat curious how you decided on this karaf list for a Dev request > for Aries. > > I’m more curious how a feature subsystem would help deploying an aries > osgi service implementation. I haven’t looked for several years at how > Aries sub projects divide up their artifact functionality, but I’d hope > that all the spec functionality, and api, would be from a single bundle, > with, possibly additional bundles for extensions. If this is how a project > is structured, how does a feature subsystem make deployment easier? If not, > would it make more sense to adopt such a structure than to imitate it with > a feature subsystem? > > Thanks > > David Jencks > > Sent from my iPhone > > > On Nov 27, 2018, at 11:27 AM, Leschke, Scott <slesc...@medline.com> wrote: > > I was wondering if there is a possibility that the Aries project would > provide OSGi Feature Subsystems for each of the OSGi services they’ve > implemented (with the exception of the subsystem spec of course). There is > a Karaf Feature for installing the Subsystem service so it would be nice if > the remaining services were available as Feature Subsystems (or Karaf > Features I guess but the former seems like a more neutral solution). > > > > Scott > > -- -- Christian Schneider http://www.liquid-reality.de Computer Scientist http://www.adobe.com
