karaf-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christian Schneider <ch...@die-schneider.net>
Subject Re: Aries
Date Wed, 28 Nov 2018 05:38:45 GMT
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>:

> 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>
> *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 <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

Mime
View raw message