On 8 March 2010 15:27, Guillaume Nodet <[email protected]> wrote: > On Mon, Mar 8, 2010 at 15:31, Graham Charters <[email protected]> > wrote: >> On 8 March 2010 14:13, Guillaume Nodet <[email protected]> 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 the >>>> maven repo will get released and need to be scrutinized, I think the >>>> 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 into >>>> 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 >>> it. >>> 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. > > 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: http://gnodet.blogspot.com/ > ------------------------ > Open Source SOA > http://fusesource.com > Cheers, Jeremy
