It's what I said: for me there's interaction not competition.
Again, we fully support OBR as resource repos in
etc/org.apache.karaf.features.cfg.
Regards
JB
On 06/15/2017 08:27 AM, Guillaume Nodet 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
--
Jean-Baptiste Onofré
[email protected]
http://blog.nanthrax.net
Talend - http://www.talend.com
