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
