aries-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Guillaume Nodet <>
Subject Re: [DISCUSSION] The nature of uber bundles.
Date Mon, 06 Dec 2010 11:30:40 GMT
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 <> 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 <> 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 <> 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
>> --
>> Cheers,
>> Guillaume Nodet
>> ------------------------
>> Blog:
>> ------------------------
>> Open Source SOA
> --
> Alasdair Nottingham

Guillaume Nodet
Open Source SOA

View raw message