aries-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Guillaume Nodet <gno...@gmail.com>
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 <not@apache.org> 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 <gnodet@gmail.com> 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 <not@apache.org> 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
>>> not@apache.org
>>>
>>
>>
>>
>> --
>> Cheers,
>> Guillaume Nodet
>> ------------------------
>> Blog: http://gnodet.blogspot.com/
>> ------------------------
>> Open Source SOA
>> http://fusesource.com
>>
>
>
>
> --
> Alasdair Nottingham
> not@apache.org
>



-- 
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com

Mime
View raw message