Hi Guillaume, Ok, that gives me a lot to chew on for now. I’ll give it a good try before I make any more speculative comments. :-)
Cheers, =David > On Jun 15, 2017, at 5:23 PM, Guillaume Nodet <[email protected]> wrote: > > > > 2017-06-15 9:00 GMT+02:00 David Leangen <[email protected] > <mailto:[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 > <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] >> <mailto:[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] >> <mailto:[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] >>> <mailto:[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 >>> >> >> >> >> >> -- >> ------------------------ >> Guillaume Nodet >> > > > > > -- > ------------------------ > Guillaume Nodet >
