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
