2017-06-15 9:00 GMT+02:00 David Leangen <[email protected]>: > > Thanks Guillaume. A lot of good food for thought. > > Again, I'm not sure why you see features competing with OBR. > > > Coming from bnd/EnRoute, in my build environment I can create different > OBRs, and “release" to them. I can use a different OBR per workspace, which > means that I can develop each “feature" separately, and release it to its > own OBR. Thus, an OBR defines a “feature”. >
No, it defines a repository, and that's fine. A feature is more than a list of bundles. OBR is useful when you want to install individual bundles. For example, if you want to deploy a web application, you could write a feature which will have a dependency on the karaf "war" feature. When you install your feature, it will ensure the web app support is deployed correctly. With OBR, you'll have a dependency on the servlet api, so the servlet api bundle will be deployed, and that's all. Of course, if you're only interested in the simple use cases, you can use an OBR repo and it will work. If you want to experiment deployment based on an OBR repo + a requirement, you could use the following file and drop it in the deploy folder: <features xmlns="http://karaf.apache.org/xmlns/features/v1.4.0";> <resource-repository>[url to the OBR repo]</resource-repository> <feature name="[feature name]" install="auto"> <requirement>[the requirement]</requirement> </feature> </features> If that's really all you need, it should be very easy to write a small karaf command that would do the same with the 3 parameters: a name, and obr repo url and a requirement. > > What I would like to be able to do is simply push the OBR into my > container, without having any extra layer. When I tried in the past, there > were some bugs and it did not work out very successfully. Maybe things have > changed since then… > > Using Apache ACE as an example, an OBR can be used in a way that is very > similar to a Feature. It works extremely well in the EnRoute environment, > and cuts down a lot of noise, IMO. > I haven't used ACE since a long time. It has very strong limitations because it's based on DeploymentAdmin which do not support deploying a bundle with multiple versions. This is a show-stopper for me. > > A feature descriptor supports the <resource-repository> element. The > content of this element is an url to a OBR repository (eventually prefixed > with json: or xml:). All features defined in the features repository will > behave as if they have the resources defined in the OBR repository with > <bundle dependency="true">xxx</bundle>. > > > Ok, either I did not know that, or I forgot about that. I’ll take a look. > IIRC I think this is what didn’t work for me when I tried some time ago. > I'd be happy to fix any bug. > > You can also provide a list of global repositories and configure it in > etc/org.apache.karaf.features.cfg with the resourceRepositories key (a > command separated list of urls). > > > The problem with this approach is, unless something has changed, I have to > restart my container each time there is a change. I would also have to > figure out a way to push the changes to Karaf. Perhaps this is easier than > I thought, but I did not find a good way last time I look into this. > Yes, that's a limited support. The reason is see problem in using this with not much value. The first option is preferrable in Karaf imho. > > Also, there's absolutely no value in the OBR bundle description compared > to a manifest. It contains the same information in a different form and is > usually generated from the manifest. Fwiw, when a feature has a reference > to a bundle, we do generate the OSGi Resource from the manifest directly > without using the OBR xml description, but it's the same. > > > True, but then again my understanding is that a properly curated OBR > should provide a set of bundles, and should not change (which is why the ID > gets updated each time there is even a minor change). The information could > very well come from the bundles, but if the bundles don’t change and the > index is trusted, then the pre-parsed manifest info is already in the > index, so it’s a duplicate effort to redo the parsing. No? > Actually, I think it's faster to parse a manifest than to the OBR xml, given the verbosity of the xml. Plus, it's an additional file to manage, so it has to provide some value, else it's not worth the pain. > > > Perhaps the Karaf/Maven way of thinking is very different from the bnd > way? Or maybe there has been convergence over the past few years, but the > tooling has not kept up? (That is what I am trying to figure out, since I > don’t know Maven very deeply, and based on what I understand, I think I > prefer the bnd way.) > Yeah, karaf tooling is definitely lacking I think. > > > Cheers, > =David > > > > On Jun 15, 2017, at 3:27 PM, Guillaume Nodet <[email protected]> wrote: > > Again, I'm not sure why you see features competing with OBR. > We do actually leverage OBR internally, and we can also leverage it > externally though it's not much advertised, but it was hinted by > Jean-Baptiste when he talked about Cave. > > OBR is the repository specification, so it defines a Repository > interface. We do have multiple implementations of it in Karaf : the > standardized XML one, a JSON based repository implementation and an in-vm > one. > > A feature descriptor supports the <resource-repository> element. The > content of this element is an url to a OBR repository (eventually prefixed > with json: or xml:). All features defined in the features repository will > behave as if they have the resources defined in the OBR repository with > <bundle dependency="true">xxx</bundle>. > > You can also provide a list of global repositories and configure it in > etc/org.apache.karaf.features.cfg with the resourceRepositories key (a > command separated list of urls). > > Also, there's absolutely no value in the OBR bundle description compared > to a manifest. It contains the same information in a different form and is > usually generated from the manifest. Fwiw, when a feature has a reference > to a bundle, we do generate the OSGi Resource from the manifest directly > without using the OBR xml description, but it's the same. > > I'm really not sure what we could do to leverage OBR more... > > > 2017-06-14 23:58 GMT+02:00 David Leangen <[email protected]>: > >> >> 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]>: >> >>> >>> 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 >> >> >> > > > -- > ------------------------ > Guillaume Nodet > > > -- ------------------------ Guillaume Nodet
