I was always wondering how to use a resource repository with Karaf.. I want to be able to leverage requirements and capabilities.. I haven't really quite figured out how to leverage them properly yet.. figuring that out is on my to do list though :)
Ryan On Wed, Nov 28, 2018, 1:23 AM Jean-Baptiste Onofré <[email protected] wrote: > 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 > > <[email protected] <mailto:[email protected]>>: > > > > 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 <[email protected] > > <mailto:[email protected]>> > > *Sent:* Tuesday, November 27, 2018 2:08 PM > > *To:* [email protected] <mailto:[email protected]> > > *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 <[email protected] > > <mailto:[email protected]>> 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é > [email protected] > http://blog.nanthrax.net > Talend - http://www.talend.com >
