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 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
