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:00:40 GMT
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

Guillaume Nodet
Open Source SOA

View raw message