Hi, I think it's related to the mail I sent last week: better and dynamic usage of resource repository with features resolver. It's what we discussed with Christian.
Clearly today, Karaf features provide unique functionalities and description, not covered by other repository (like subsystem or resource repository), I'm thinking about configuration, features flags, inner features, etc. However, it would make sense to start Karaf with a minimal features set and then leverage resources repositories at runtime, dynamically. The first step I proposed is basically to add commands to manipulate the resources repository at runtime and add resource repository element in features repositories. Today, it's already possible to use resources repositories, defining it (in XML or JSON) in etc/org.apache.karaf.features.cfg. This configuration is evaluated when the features service starts and used by the features resolver. The propose is: 1. add resource:repo-add and other commands to add/remove resource repositories at runtime and then perform a new evaluation of the resolution. 2. add <resource/> element in features repo (as we have <repository/>) allowing to define "open" features and relay on resources repository. So, to be clear, I don't want to change the current features service which, again, provide unique features, and it's the minimal layer to start a karaf runtime. My proposal is to extend & improve the features service to better leverage the resources repositories. The user then can focus only on a resource repository and won't be "forced" to use a features repository. Regards JB On 28/11/2018 06:38, Christian Schneider wrote: > 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 <mailto: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 > <mailto:david.a.jen...@gmail.com>> > *Sent:* Tuesday, November 27, 2018 2:08 PM > *To:* user@karaf.apache.org <mailto: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 > <mailto: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 > -- Jean-Baptiste Onofré jbono...@apache.org http://blog.nanthrax.net Talend - http://www.talend.com
