aries-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeremy Hughes <>
Subject Re: Aries release - the shape of repo org/apache/aries
Date Tue, 09 Mar 2010 16:29:26 GMT
On 9 March 2010 14:14, Graham Charters <> wrote:
> On 8 March 2010 22:00, Jeremy Hughes <> wrote:
>> On 8 March 2010 15:27, Guillaume Nodet <> wrote:
>>> On Mon, Mar 8, 2010 at 15:31, Graham Charters <>
>>>> On 8 March 2010 14:13, Guillaume Nodet <> wrote:
>>>>>> For now I'm just interested in the groupIds and artifactIds of the
>>>>>> artifacts we expect users to use. While everything in our part of
>>>>>> maven repo will get released and need to be scrutinized, I think
>>>>>> artifacts below are the ones we should list on our download page
>>>>>> (along with 'project' tar.gz files which can be used to build the
>>>>>> binary). I've also follwed the 'best practice' of separating APIs
>>>>>> an API bundle:
>>>>> This is not a good practice in OSGi imho.
>>>>> Actually it does not help in any way and just cause more problems for
the user.
>>>>> The reason is that OSGi can substitute an API for another package, so
>>>>> we just need
>>>>> to make sure our big bundles do import the API package along with exporting
>>>>> People can obtain the API alone if they want to or need it to
>>>>> repackage it differently,
>>>>> but the basic distribution should be a standalone bundle if possible.
>>>> I think there are two separate concerns here:
>>>> 1. Substitutability - a bundle that provides an API it doesn't own the
>>>> definition for should import and export it.  This allow multiple
>>>> potential providers to be installed whilst ensuring that only a single
>>>> provider is eventually used.
>>> Agreed.
>>>> 2. Implementation Upgrade - the ability to upgrade an implementation
>>>> (service) without having to refresh the clients.  IIUC, this only
>>>> works if you have separate bundles providing the API and
>>>> implementation.  The client only depends on the API and therefore does
>>>> not need to be refreshed (package-wise) when the implementation is
>>>> replaced.
>>> I do understand potential problems and limitations, but then there's
>>> no point in having a single bundle.
>>> The main driver was easy of consumption.  If users have to download
>>> and install multiple bundles, then
>>> we should not ship it at all.
>> I agree we should ship a single bundle for ease of consumption. I'd
>> also like to ship API because there are scenarios where that's useful.
> At first I thought this was the right answer, but I now don't believe
> it solves the upgrade problem.  There is no way, other than ordering,
> which is bad in a dynamic environment. to ensure the API bundle is the
> provider of the APIs.  The resolver could just as easily chose the
> ones from the single implementation bundle, in which case there was no
> point installing the API bundle and the upgrade strategy is broken.

So to get ease of consumption we'll release an 'uber' bundle with api
and impl in it.
For people who want to implement the api themselves (!) we'll make the
api bundle available.
For people who want to make use of being able to hot-replace the
implementation at runtime (and granted this may not be applicable to
all modules) we should release api and separate 'impl-only' bundles.

Unless you see another possibility.

>>> In addition, even if what you say is conceptually a good idea, it does
>>> not really work for blueprint.
>>> The effect of upgrading the blueprint implementation will be far more
>>> disruptive than having to refresh
>>> the bundles that use the blueprint API: in that case, all blueprint
>>> context will be shut down and restarted,
>>> so I don't really think this point is really valid.
>> OK, that's true for Blueprint. Not necessarily the case for others
>> though. One of the promises of Blueprint is to facilitate dynamicity
>> of services. One way those services can come and go is if the provider
>> of those services is hot-updated when, say, a bug fix update is
>> available. If, where possible, we demonstrate this by way of
>> separating API & impl bundles then we can demonstrate this model.
>>> Additionally, we could go further down the path and say that you may
>>> want to refresh the CM support without
>>> refreshing all the blueprint implementations, so we should not tie
>>> them together.
>>> I think at the end, it's really a tradeoff between micro-management of
>>> bundles and ease of use.  If you want
>>> to be able to minimize changes for each bundle, use smaller bundles.
>> Agreed, if we give users the choice of taking an 'uber' bundle or a
>> set of bundles then they have the flexibility to choose what to do
>> themselves.
>>> If you want to manage your bundles
>>> more easily and don't worry too much about refreshing, your more
>>> coarse grain bundles.
>>> We already have small bundles.
>>> Last, the spec actually mandate the implementation exports the api.
>>> It may even be problematic to export it.
>>> The reason is to support multiple blueprint implementation.   The
>>> additional requirement IIRC is that each
>>> blueprint bundle should import the org.osgi.service.blueprint package.
>> +1
>>> I think we should comply to that, because we have users who will want
>>> to use migrate their existing spring applications
>>> at a slower rate and we should be able to support both running in the same vm.
>>> Maybe a good idea would be to add a non mandatory attribute on the
>>> org.osgi.service.blueprint package to allow
>>> blueprint bundles to make sure they are extended by the aries
>>> blueprint implementation.
>>> --
>>> Cheers,
>>> Guillaume Nodet
>>> ------------------------
>>> Blog:
>>> ------------------------
>>> Open Source SOA
>> Cheers,
>> Jeremy

View raw message