karaf-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jean-Baptiste Onofré ...@nanthrax.net>
Subject Re: Aries
Date Wed, 28 Nov 2018 06:22:44 GMT

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.


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
> <SLeschke@medline.com <mailto:SLeschke@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.jencks@gmail.com
>     <mailto:david.a.jencks@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 <SLeschke@medline.com
>     <mailto:SLeschke@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é
Talend - http://www.talend.com

View raw message