Thank you JB and Christian, I think that about answers my question. Right now I don’t have time to actually invest in doing anything about it, but I was just curious. :-)
Cheers, =David > On Jun 15, 2017, at 1:49 AM, Jean-Baptiste Onofré <[email protected]> wrote: > > 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 <[email protected] >> <mailto:[email protected]>>: >> 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é > [email protected] > http://blog.nanthrax.net > Talend - http://www.talend.com
