aries-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alasdair Nottingham <...@apache.org>
Subject Re: [DISCUSSION] The nature of uber bundles.
Date Mon, 06 Dec 2010 13:23:43 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.

This wouldn't happen by magic though. Someone would have to do refresh packages
to cause blueprint to be reresolved, and then only if the util/proxy
bundle was uninstalled.
So while I understand the concern it isn't going to happen by magic,
someone would have
to perform an explicit action.

> I'm more worried about
> the runtime behavior of those components than a few wasted kilobytes
> of memory.

It isn't just the wasted kilobytes that worry me, but the additional
complexity involved
when consuming multiple components.

> #1 is just a convenience as the bundle has some dependencies anyway
> (so it just remove a few of them),

I agree.

> while #2 actually has an impact on
> the runtime I think.
>

I'm not sure I follow your comment here. I think #2 has the lesser
impact on runtime
because it contains all its dependencies.

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



-- 
Alasdair Nottingham
not@apache.org

Mime
View raw message