Hi Guillaume, Thank you for this assessment.
I agree that Features adds value. Your post explains a lot of good reasons why this is so. My question is more about “why compete with OBR?”. Instead of embracing OBR and working on top of it, it seems that Features want to replace it. This is causing me to have to make a lot of choices in my deployment mechanism. Features could be really helpful for deployment by managing OBRs, configurations, and other deployment information. They could also manage versioning better etc. Maybe something like what Apache ACE was trying to do. However, instead of “adding” value, currently Features are completely replacing OBR, which I find interesting. But I understand that there is some legacy to this. Now that it works, it would take some momentum to move to a more standards-based approach. My current issue is: how can I use Features for Continuous Deployment? I am having trouble with automation. That is what got me interested in the idea behind the Features… Cheers, =David > On Jun 15, 2017, at 6:38 AM, Guillaume Nodet <[email protected]> wrote: > > So if you consider an OBR as being a collection of resources, each resource > having capabilities and requirements, then a feature repository is an OBR > repository, it's just the syntax is more concise. > If you want to look at what the repository look like, you can launch the > following command in karaf: > > feature:install --store resolution.json --verbose --simulate scr > > Then, look at the resolution.json file, it will contain the OBR repository > used by the resolver in a json format. The xml syntax would be slightly > different of course, and a bit more verbose too, but roughly the same data. > I do think the features syntax is a bit more understandable. > > But you do not want to compare OBR and features. I haven't seen any OBR > repository used which would contain other things than just OSGi bundles. > Features is more a deployment artifact than an OSGi bundle, so it's more to > be compared with OSGi subsystems. > > With pure OBR, you can't group bundles together, you usually don't want to > edit such a repository file manually, so at the end, you can never really > hack the content. It has to be generated, and is mostly generated only from > a set of OSGi bundles. You can't capture all the constraints by using > bundles only. > > 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 > > > > > > -- > ------------------------ > Guillaume Nodet >
