I recently had the luxury of being able to impose my preferences on the whole team, because I was the whole team. ;-) Here's what I did:
1) Bundle naming convention different to package name conventions - I used two- or three-word names in CamelCase e.g. ShimmerPolishApi for the polishing API of the Shimmer product. 2) Bundles generally containing more than one package. If you sometimes need to look up the bundle which contains a given package there are ways enough to do so. 3) Strict segregation between Api and Impl bundles. The Impl bundle re-exports the corresponding Api packages. Only Api bundles may be build dependencies. Only Impl bundles are deployed at runtime. 4) Use a resolver. You do need to keep an eye open to stop e.g. the bloody Felix web console from bringing in two versions of the SCR, but still it's better than chasing resolution errors. 5) Use bndtools. Shun PDE. Of course on a one-man project almost any system of organisation will work, but these recommendations are all based on larger projects I've worked on. HTH Chris > Regarding 1). I tend to have more than one package in a bundle (albeit, > fairly coupled packages, as one should expect in this case). Bundle > equates to coarse-grain component while package equates to more finer > grain software construct(s). > > Regarding 2). As per having more than one package in a bundle, it is > expected that versions of packages would vary independently of the bundle > version. > > While on the subject - I separate API packages/bundles from Implementation > packages/bundles, where "API" mayr or may not necessarily equate to a Java > Interface construct. > > As always, avoid circular dependencies between packages (and, thus, > bundles). There are other means to accomplish inter-communication without > resorting to circles. > > HTH > > ________________________________ > From: osgi-dev-boun...@mail.osgi.org [osgi-dev-boun...@mail.osgi.org] on > behalf of Endo, Alejandro [alejandro.e...@grassvalley.com] > Sent: Monday, November 02, 2015 12:05 PM > To: OSGi Developer Mail List > Subject: [osgi-dev] common osgi confussions > > 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 doesnt > 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. Ive 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 its 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. Im thinking of changing the symbolic name delimiter to make it > more obvious that the concepts are orthogonal. So even if they dont 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 dont 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 theres 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 cant find, wth?? Now, compound this with point #1, > which I didnt do here for clarity, but in reality it looks more like > bundle x.y.z cant start because its 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 Im considering > (again from Peter in the jigsaw EG) is to use a hash (gits) 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 cant 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 _______________________________________________ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev
