On 26.11.2015 11:40, David Leangen wrote:
This corresponds to how I use it. The dependencies are defined in the
application bundle via annotations, and a default configuration is
also provided in the bundle. All the bndrun file is is an index of the
results of what happens when you hit “resolve”.
These annotations will create the requirements of the bundle Manifest.
It is not guaranteed though that this describes all of your application.
My understanding is that Karaf IS the runtime, and can do the
resolution at runtime, so there is really no need for a bndrun file.
It depends on the use case who does the resolve. In the application mode
bndtools would do the resolving and you would not use the karaf resolver.
In the server use case you would let karaf do the resolve at runtime.
In both cases a bndrun or similar is necessary. The bndrun file does not
only contain the runbundles which is the already resolved list. It also
contains the requirements. The minimum thing it would contain in your
case is
a pointer to your application bundle. In many cases it will contain a
list of requirements for bundles and maybe other requirements.
This part of the bndrun file is the input for the resolver. This is
always needed.
On the other hand features can define things that you might overlook
when just using a bndrun file. So for example CXF would like to
replace certain jdk built in specs and impls for security or
performance reasons. These things are more difficult to express in
the form of a bndrun file.
Yes, agree. For this, some extension mechanism would be required in
addition to the OBR + requirements. As you mentioned previously,
eventually if this were part of the OBR spec, it would be ideal.
It is the purpose of a feature file or a bndrun file. The obr index is
just the pool of bundles/resources to pick from. You need to give the
resolver the initial hooks to pull the needed bundles out of this pool.
Christian
--
Christian Schneider
http://www.liquid-reality.de
Open Source Architect
http://www.talend.com
