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+features+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.bndrun#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=3aa4083e0c744ae1ba52bd062c5a7e46&URL=http%3a%2f%2fwww.liquid-reality.de>
Open Source Architect
http://www.talend.com
<https://owa.talend.com/owa/redir.aspx?C=3aa4083e0c744ae1ba52bd062c5a7e46&URL=http%3a%2f%2fwww.talend.com>
--
Jean-Baptiste Onofré
jbono...@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com
