Hello everyone, My team has been using OSGi for over 2 years now but I still have to clarify something quite often, so I am hoping I can improve this to reduce development issues so that non-osgi developers (especially new hires) can deal with versioning and dependency resolution without needing to know all the internal details of OSGi
There are basically two problems that arrive quite often 1) Package name != bundle name: the naming convention we are using makes it hard to differentiate between a symbolicName and a java package. The recommended way that I found when we started using OSGi was to make the symbolic name match the java packages inside, but now I think this is confusing. Plus, there are some bad cases where the symbolic name doesn't match the package name, in that case the person will spend a long time wondering where is that bundle called foo.hello when in reality foo.hello is the *package* and it is part of a bundle called my.bar.hello. I've been following the jigsaw expert group that Peter is part of and I have hear some suggestions of using a different delimiter for bundle names to avoid this. What do you guys think about this? We use PDE so I personally rely on the icon that PDE shows when complaining about missing dependencies. Otherwise, in the actual java log you just need to know the fact that OSGi uses packages for dependencies but that packages are packaged in bundles so when you see a bundle complaining, the bundle itself is a symbolic name, but it's missing dependency is a java package. This is a lot of internal OSGi details for most developers whose tasks are to implement new features or fix bugs without having to think of the architecture of our system. I'm thinking of changing the symbolic name delimiter to make it more obvious that the concepts are orthogonal. So even if they don't know all the internal details, they will know that a missing dependency a.b.c cannot be resolved just with a bundle a_b_c or a-b-c. Are there any drawbacks you guys have encountered? Is there a better technique? 2) Package version != bundle version: This is even more surprising if you don't know how dependency resolution works in OSGi. Imagine a bundle foo_1.0.0 exports package a.b.c_1.0.0 and a.b.d_1.0.0. Then there's a bugfix on a.b.c so it becomes 1.0.1 and the bundle version also 1.0.1 (a.b.d stays 1.0.0). Then another bugfix this time on a.b.d so it becomes 1.0.1 and the bundle 1.0.2 (a.b.c stays at 1.0.1). Then someone runs another bundle "bar" which depends on a.b.d 1.0.1 but installs foo version 1.0.1 (which has a.b.d at 1.0.0). They are usually (and understandably) really surprised that osgi is complaining about missing a.b.d 1.0.1 but see that foo contains the package a.b.d and that the version of the bundle is 1.0.1. The thought process is probably along the lines "I have the right bundle selected and its version is the version that OSGi says it can't find, wth??" Now, compound this with point #1, which I didn't do here for clarity, but in reality it looks more like "bundle x.y.z can't start because it's missing dependency a.b.d_1.0.1 (the package)" but they check and bundle a.b.d 1.0.1 (the symbolicName) is indeed selected and running, but its exported package a.b.d. is still 1.0.0. What do you guys recommend for this? One option I'm considering (again from Peter in the jigsaw EG) is to use a hash (git's) for the bundle version. Any thoughts on this? One of the worries I have is losing the ordering of bundles (i.e. if given two bundles, you can't easily know which bundle is newer) specially that for some not-optimal architectural separation we use Require-Bundle with a range, which would not work with such a technique. Thanks for any thoughts or best-practices shared, Alejandro Endo DISCLAIMER: Privileged and/or Confidential information may be contained in this message. If you are not the addressee of this message, you may not copy, use or deliver this message to anyone. In such event, you should destroy the message and kindly notify the sender by reply e-mail. It is understood that opinions or conclusions that do not relate to the official business of the company are neither given nor endorsed by the company. Thank You.
_______________________________________________ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev
