On 03.12.2015 10:40, David Leangen wrote:
Hi,
By the way, bndtools does have a concept of a deployment descriptor
(bndrun). All it is, really, is just an index of the resolved
bundles, i.e. the bundles that are available in the workspace, and
are therefore available to the runtime. The list is simply the
output of the resolve operation, nothing more. This could easily be
done at runtime as well.
The result of the resolve in bndtools is not the list of bundles in
the workspace. It is the list of the bundles to be installed.
Yes, that is exactly what I meant, but that the list of bundles is
taken from the bundles that are available in the workspace. The
resolved bundles are only those that are available (in the workspace)
at the time of resolution.
Please correct me if I am mistaken, but won’t something strange like
the following happen?
Suppose that my workspace has felix scr v2.2.3 (or whatever).
Suppose that Karaf has felix scr v2.1.2 (for instance)
I the build-time resolution uses only what is available in my
workspace at the time, then my features.xml will contain felix scr
v2.2.3. So, when I want to run in Karaf, which only has the older
version 2.1.2, I will need to pull in the newer version. Now I have 2
versions of scr running in my system. Now imagine this for all such
bundles, and the runtime system becomes a big mess, and the whole
point of componentization gets lost.
Or am I misunderstanding how this works?
You are correct a plain feature generation out of the resolved bundles
would create this result.
One way to make it easier is if we provide an index for all or at least
the basic karaf features per karaf version. You could then add this
index to you bndtools workspace and have a
better resolution already at build time.
I think if you want to do the full resolution in bndtools (application
mode) this is the best way to go.
Christian
Cheers,
=David
--
Christian Schneider
http://www.liquid-reality.de
Open Source Architect
http://www.talend.com
