On reviewing this thread I realised I hadn't responded to this point email.
On 6 December 2010 14:47, Guillaume Nodet <[email protected]> wrote: > Optional packages are only resolved while doing a refresh, This is not true. Optional packages are resolved when the bundle is installed, if the package is missing then the import will be dropped and a refresh is required to pick it up. This means their is a possible ordering constraint when installing bundles so if I have > A imports a package from B > install bundle C which provide an optional package for B > install bundle D which uses that optional package > > In order for D to see the correct package wiring, bundle B needs to be > refreshed, which afaik makes the old wiring goes away, meaning C will > be refreshed too. I don't really follow your example. bundle D can only use packages it imports. I assume you mean bundle D uses a capability provided by bundle C only if package B is wired? In any case I believe your scenario would result in the correct resolution with some frameworks such as equinox which resolve bundles as a group. A smart provisioner should be able to detect it is installing A, B, C and D and install them in the right order. If C were installed a long time after A and B then I think this is just what you get. > The same is true for fragments btw. > > Updating a bundle does actually have no effect on existing wirings > though. I'm wondering if doing the following would work: > * install C > * update B (without any actual change) > * install D > * resolve D > Not sure if D would actually get a version of B with the correct wiring. > > On Mon, Dec 6, 2010 at 15:32, Jeremy Hughes <[email protected]> wrote: >> On 6 December 2010 11:30, Guillaume Nodet <[email protected]> wrote: >>> What I really fear is that i don't want to impact blueprint and have >>> all blueprint bundles to be re-extended because the blueprint extender >>> has been refreshed without any real need as a side effect of upgrading >>> the util module for another aries component. I'm more worried about >> >> Why would you have to refresh the blueprint extender? If you install a >> new version of the util bundle, Blueprint can carry on using the old >> one while other bundles use the new one - as long as you pass the >> right bundles into refreshPackages. Surely? What am I missing? >> >>> the runtime behavior of those components than a few wasted kilobytes >>> of memory. >>> #1 is just a convenience as the bundle has some dependencies anyway >>> (so it just remove a few of them), while #2 actually has an impact on >>> the runtime I think. >>> >>> >>> On Mon, Dec 6, 2010 at 12:05, Alasdair Nottingham <[email protected]> wrote: >>>> I really want a number 1. I pull all of the aries modules into my >>>> product and currently I get multiple copies of util, and I have >>>> multiple versions of ASM. >>>> >>>> I know I could go with the individual bundles too, but this has it's >>>> own negatives, such as having a huge number of extra bundles. >>>> >>>> I understand the need for #2, but I strongly believe we should have a >>>> #1 and certainly when we first discussed uber bundles I was expecting >>>> more of a #1 than a #2. >>>> >>>> Alasdair >>>> >>>> On 6 December 2010 11:00, Guillaume Nodet <[email protected]> wrote: >>>>> I'm not really sure about #1. My main use case is more for #2 where >>>>> i'd want a standalone and highly cohesive bundle. >>>>> In all cases, i agree we should rationalize what we currently have. >>>>> >>>>> On Mon, Dec 6, 2010 at 11:57, Alasdair Nottingham <[email protected]> wrote: >>>>>> Hi, >>>>>> >>>>>> While I was working on making the proxy code common between blueprint >>>>>> and JNDI I noticed that many of our components have a *-bundle module, >>>>>> to build an "uber" bundle, but we seem to have slightly different ways >>>>>> of building these bundles. We seem to build uber bundles in one of >>>>>> three ways: >>>>>> >>>>>> 1. The uber bundle contains all the other modules in the same top level >>>>>> module >>>>>> 2. The uber bundle pulls in some subset of other top level models >>>>>> (e.g. proxy and blueprint pull in the util bundle) >>>>>> 3. The uber bundle pulls in all mandatory dependencies (e.g. blueprint >>>>>> pulls in asm). >>>>>> >>>>>> I think it would make sense to have a common approach and as a result >>>>>> I would like to propose the following: >>>>>> >>>>>> 1. The uber bundle. This bundle collects all the relevant child >>>>>> modules of the module. An uber bundle does not collect other modules >>>>>> like proxy or util. Such a bundle is not standalone. So a blueprint >>>>>> uber bundle would collect blueprint-api, blueprint-core, blueprint-cm, >>>>>> but not util or proxy. A proxy uber bundle collects proxy-api, >>>>>> proxy-impl. >>>>>> 2. The nodeps bundle. This is a truely standalone bundle that includes >>>>>> everything it needs. It is standalone. So the blueprint nodeps bundle >>>>>> would pull in the util, proxy modules and asm. >>>>>> >>>>>> I think this balances the desire for ease of deployment with the >>>>>> desire for better sharing and modularity and minimum duplication of >>>>>> code. >>>>>> >>>>>> What do people think? >>>>>> Thanks >>>>>> Alasdair >>>>>> >>>>>> -- >>>>>> Alasdair Nottingham >>>>>> [email protected] >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> Cheers, >>>>> Guillaume Nodet >>>>> ------------------------ >>>>> Blog: http://gnodet.blogspot.com/ >>>>> ------------------------ >>>>> Open Source SOA >>>>> http://fusesource.com >>>>> >>>> >>>> >>>> >>>> -- >>>> Alasdair Nottingham >>>> [email protected] >>>> >>> >>> >>> >>> -- >>> Cheers, >>> Guillaume Nodet >>> ------------------------ >>> Blog: http://gnodet.blogspot.com/ >>> ------------------------ >>> Open Source SOA >>> http://fusesource.com >>> >> > > > > -- > Cheers, > Guillaume Nodet > ------------------------ > Blog: http://gnodet.blogspot.com/ > ------------------------ > Open Source SOA > http://fusesource.com > -- Alasdair Nottingham [email protected]
