Optional packages are only resolved while doing a refresh, 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. 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
