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 >
