aries-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeremy Hughes <hugh...@apache.org>
Subject Re: [DISCUSSION] The nature of uber bundles.
Date Mon, 06 Dec 2010 14:32:39 GMT
On 6 December 2010 11:30, Guillaume Nodet <gnodet@gmail.com> 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 <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