Hi Christian, Thanks for this information.
> There is one big downside to OBR unfortunately. Inside OBR the content of > bundles needs to be refered as a url. While karaf can work with mvn urls > other systems like bndtools can not. Now the problem is that you can not > populate an OBR well without maven urls if your artifacts reside in maven and > you also want to use maven SNAPSHOTs. My understanding is that this is very much by design. The reason is to have a “strongly” curated repository to promote well-behaved and predictable builds and deployments. I could be wrong. Maybe would be good to verify with some of the alliance peeps. > Another solution is to consider the OBR just as a cache and define the list > of bundles in a pom. Bndtools is going that way and I think karaf could do > the same. So a feature could simply point to a pom or when deployed to maven > we could assume to use the pom of the project the feature resides in as > default. This would allow to simply define OBRs by using a pom. You think bndtools is going that way? Or rather, they are just trying to bring in more Maven people? I don’t understand what the purpose would be. If the bundles are already defined in the OBR, why have a second list? Cheers, =David > On Jun 15, 2017, at 3:18 PM, Christian Schneider <ch...@die-schneider.net> > wrote: > > There is one big downside to OBR unfortunately. Inside OBR the content of > bundles needs to be refered as a url. While karaf can work with mvn urls > other systems like bndtools can not. Now the problem is that you can not > populate an OBR well without maven urls if your artifacts reside in maven and > you also want to use maven SNAPSHOTs. > > So I think there is a gap in OBR that needs to be closed. One solution would > be to add the mvn urls to the spec so they are universally accepted. > > Another solution is to consider the OBR just as a cache and define the list > of bundles in a pom. Bndtools is going that way and I think karaf could do > the same. So a feature could simply point to a pom or when deployed to maven > we could assume to use the pom of the project the feature resides in as > default. This would allow to simply define OBRs by using a pom. > > Christian > > > 2017-06-14 23:58 GMT+02:00 David Leangen <apa...@leangen.net>: > > 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 <gno...@apache.org> 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 <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 >> >> >> >> >> >> -- >> ------------------------ >> Guillaume Nodet >> > > > > > -- > -- > Christian Schneider > http://www.liquid-reality.de > > Open Source Architect > http://www.talend.com
