No, the OSGi Repository spec.
Regards
JB
On 06/14/2017 08:43 PM, Leschke, Scott wrote:
When we say "OBR" are we referring to the OSGi Subsystem spec?
Scott
-----Original Message-----
From: Jean-Baptiste Onofré [mailto:j...@nanthrax.net]
Sent: Wednesday, June 14, 2017 11:49 AM
To: user@karaf.apache.org
Subject: Re: Karaf Feature vs. OBR
And anyway, Karaf Features can leverage OBR (directly or via Cave).
Karaf can load OBR repos in org.apache.karaf.features.cfg and use it directly.
Regards
JB
On 06/14/2017 06:46 PM, Christian Schneider wrote:
Hi David,
I think the reason is more that features in karaf used to work a lot
simpler in the start. They were simply a list of bundles to install.
Over time features got more and more abilities.
So it is less to lock in people and more simply a history matter.
Since karaf 4 features use the felix resolver. You can imagine a
feature as a mix of obr and requirements for the resolver.
If a bundle in a feature is marked as dependency=true then it behaves
in the same way as a bundle listed in an OBR if the feature is
installed. It is simply there to be selected if necessary. If
dependency=false (the default) then the bundle is also a requirement for the
resolver if the feature is to be installed.
I agree with you that it would be great to move to a more general way
that then also works in different environments.
Some time ago I wrote down some ideas for a feature replacement that
is less karaf specific.
http://liquid-reality.de/display/liquid/Design+repository+based+featur
es+for+Apache+Karaf
The main things features provide:
- List of bundles to choose from
- List of bundles to install (requirements)
- Configs to install
- Conditionally install additional bundles if other features are
present
The first three things can already be done without features:
- An OBR index can supply the list of bundles to choose from ( I
already started to provide OBR repos in some projects like Aries RSA)
- We could use a list of top level bundles as initial requirements
- A bundle can require other bundles using Require-Bundle headers.
This could allow feature like bundles that list other top level
bundles
- Configurations can be provided inside of bundles using the
Configurer spec and impl from enroute
For conditional bundles there is no replacement outside of features.
So we could develop a replacement of features that works in all OSGi
environments. It is just matter of knowledge and effort to implement this.
You can see in the CXF-DOSGi SOAP sample what can already be done
with OBR and a resolver:
https://github.com/apache/cxf-dosgi/blob/master/samples/soap/soap.bndr
un#L1-L41 The runbundles are automatically determined by the resolver.
As you can see it is already possible but still quite a bit more
effort than with karaf features at the moment.
Christian
2017-06-14 7:49 GMT+02:00 David Leangen <apa...@leangen.net
<mailto:apa...@leangen.net>>:
Hi!
I am trying to wrap my head around the differences between an OBR and a
Karaf Feature. The concepts seem to be overlapping.
An OBR has an index of the contained bundles, as well as meta information,
which includes requirements and capabilities. An OBR is therefore very
useful for resolving bundles, and partitioning bundles into some kind of
category. It can also be versioned, and can contained different versions of
bundles. An OBR could potentially be used to keep snapshots of system
releases. I believe that this is somewhat how Apache ACE works. (A
Distribution can be rolled back by simply referring to a different OBR and
allowing the system to re-resolve.) The actual bundles need to be stored
somewhere. The OBR index needs to provide links to that storage.
A Karaf Feature is basically an index of bundles (and configurations), too.
I think that it can also be versioned, and can contain different versions
of
bundles. Like an OBR, it is very useful for partitioning bundles into some
kind of category, so the groups of bundles can be manipulated as a single
unit. Just like an OBR, the Karaf Feature also needs to provide a link to
the bundles. AFAIU, resolution is done somehow in Karaf, based on the
bundles available via the Features, so in the end the entire mechanism
seems
almost identical to what the OBR is doing.
So many similarities!
I understand that a Feature can include configurations, which is nice, but
why have a competing non-official standard against an official standard? If
configurations is the only problem, then why not build it on top of OBRs,
rather than creating something completely new and different and competing?
Is it to try to force lock-in to Karaf? Or am I completely missing
something?
Thanks for explaining! :-)
Cheers,
=David
--
--
Christian Schneider
http://www.liquid-reality.de
<https://owa.talend.com/owa/redir.aspx?C=3aa4083e0c744ae1ba52bd062c5a7
e46&URL=http%3a%2f%2fwww.liquid-reality.de>
Open Source Architect
http://www.talend.com
<https://owa.talend.com/owa/redir.aspx?C=3aa4083e0c744ae1ba52bd062c5a7
e46&URL=http%3a%2f%2fwww.talend.com>
--
Jean-Baptiste Onofré
jbono...@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com
--
Jean-Baptiste Onofré
jbono...@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com
