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