It depends the requirements and the way it's generated.
Karaf feature address this use case thanks to dependency/prerequisite flag.
Regards
JB
On 12/03/2015 10:40 AM, 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?
Cheers,
=David
--
Jean-Baptiste Onofré
jbono...@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com
