Hi, Based on this discussion I am going to change our <module>-bundle modules to follow the model #1 described in my previous note.
This will remove the utils components from blueprint, but I do not think that is a huge issue. The main concern I think might be that the proxy support optionally imports asm, but I could make this import required which would solve that issue. I'll also make asm a mandatory dependency rather than optional. I'll raise a JIRA. Thanks Alasdair On 19 December 2010 11:40, Alasdair Nottingham <[email protected]> wrote: > 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] > -- Alasdair Nottingham [email protected]
