I just did a Google search for apache cave nexus to see if anybody provided a comparison, and this is what I found:
https://books.google.co.jp/books?id=JC3QD47hu24C&pg=PA280&lpg=PA280&dq=apache+cave+vs+nexus&source=bl&ots=zyJRNO8SlK&sig=qlaz61q4d7s8PbrYFEZnnQP-tlc&hl=en&sa=X&ved=0ahUKEwjphJXJjb7UAhUES7wKHVk8BXgQ6AEILDAB#v=onepage&q&f=false <https://books.google.co.jp/books?id=JC3QD47hu24C&pg=PA280&lpg=PA280&dq=apache+cave+vs+nexus&source=bl&ots=zyJRNO8SlK&sig=qlaz61q4d7s8PbrYFEZnnQP-tlc&hl=en&sa=X&ved=0ahUKEwjphJXJjb7UAhUES7wKHVk8BXgQ6AEILDAB#v=onepage&q&f=false> An Apache Life-Way … the first moccasin game was played there in a hint of such a nexus. “At the bottom of this hole, a cave… :-) =David > On Jun 15, 2017, at 4:47 AM, David Leangen <[email protected]> wrote: > > > 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 >
