Re: Aries

[Ryan Moquin <fr...@gmail.com>]

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é <jb@nanthrax.net 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
> > <SLeschke@medline.com <ma...@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
> >     <ma...@gmail.com>>
> >     *Sent:* Tuesday, November 27, 2018 2:08 PM
> >     *To:* user@karaf.apache.org <ma...@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
> >     <ma...@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é
> jbonofre@apache.org
> http://blog.nanthrax.net
> Talend - http://www.talend.com
>