Craig, one example please of a classic DO NOT DO THIS for application builds?

[Bill Johnston]

Criag,

I'd really appreciate it if you would be able to offer one significant "DON'T DO", that can be applied to desktop application design and development as well as web dev, as an example of what you "talk" about in your book?

[Craig Walls]

Bill Johnston wrote:I'd really appreciate it if you would be able to offer one significant "DON'T DO", that can be applied to desktop application design and development as well as web dev, as an example of what you "talk" about in your book?

I'm not sure if this is what you're looking for, but...

DO NOT develop/package/deploy all of your application functionality in a single monolithic unit. From a development standpoint, this means using something like Maven modules to develop each piece of your application as a standalone unit. The same thing also applies from a packing standpoint. For deployment a modular framework such as OSGi lets you take those individually developed/packaged units and deploy them individually. (Without OSGi, you would usually take all of those nicely distinct deployment units and wrap them all up in a single WAR file for deployment, thus losing out on the runtime modularity OSGi offers).

Here's another:

DO NOT disregard the power of interface-driven development. This means that even if you think you only need a single implementation of something, still go ahead and hide that implementation behind a stable interface and only work with it through that interface. The loose-coupling benefits of working with interfaces far outweigh the tiny cost of creating those interfaces. These benefits make themselves evident in many places including OSGi, Spring, and unit-testing.

Another, more directly related to OSGi...

DO NOT use Require-Bundle: unless you absolutely understand and can accept the consequences of doing so. Require-Bundle: will couple one bundle directly to another bundle by its name. That means that the depending bundle will not work if the dependency is unavailable (even if there are suitable substitutes available). Instead express dependencies at the package level using Import-Package:. Import-Packages specifies a dependency more generically on a Java package and not on any specific provider of that package.

Finally, another OSGi-specific "thou shalt not"...

DO NOT write and manage the META-INF/MANIFEST.MF file by hand. That's just nuts. Lean on tools such as BND, the Felix Maven Bundle plugin, Pax Construct, SpringSource's Bundlor and other such things to do all of the heavy lifting for you.

How's that?

[Bill Johnston]

Thank you Craig - that's actually even more than I asked. Makes me want to learn more.

[Hong Anderson]

Craig Walls wrote:
DO NOT disregard the power of interface-driven development. This means that even if you think you only need a single implementation of something, still go ahead and hide that implementation behind a stable interface and only work with it through that interface. The loose-coupling benefits of working with interfaces far outweigh the tiny cost of creating those interfaces. These benefits make themselves evident in many places including OSGi, Spring, and unit-testing.

I agree with this. For me, using interfaces is not just because they are or could be several implementations. Another reason is the callers needn't to know *how* the services work (what are the implementations), they just need to know what are provided by the services.

[Craig Walls]

Here's another OSGi-specific DO NOT...

DO NOT (or at least, you should avoid) splitting packages across multiple bundles. A split package is one where there are some classes/resources of the package in one bundle and some more in another bundle. Aside from being a very non-modular thing to do, it confuses OSGi.

For example, let's say that you have two classes: com.javaranch.Foo and com.javaranch.Bar. If each of these is in a separate bundle, then when OSGi tries to satisfy a package import for com.javaranch, it will find one of them, and stop looking. So, the bundle(s) that imports com.javaranch will only get Foo or Bar, but not both.

That said, you can't control what 3rd party libraries look like and sometimes you'll encounter split packages. Compass, for example, depends on Lucene. But Compass also has some custom Lucene packages embedded within its own JAR. That means that those packages are split between Compass and Lucene. This creates a special form of the split package problem where Compass will find its own content and not bother importing the Lucene content it depends on.

There are two ways to fix this: If nothing else in your app depends on Lucene, then you could wrap the Compass JAR and embed Lucene within it (I show how to do this exact thing in the book). Or, you could wrap Compass and use Require-Bundle: to specify the Lucene dependency in Compass' MANIFEST.MF. By using Require-Bundle:, the Compass bundle will pull in everything in the Lucene bundle even if it has packages that collide with its own packages.

Yes, I know...I said never use Require-Bundle:. But split packages are one place where Require-Bundle: can be helpful. That is, you have one ugly problem to solve and it needs an ugly solution to solve it. Either way...it's ugly.

[Hong Anderson]

Craig Walls wrote:
For example, let's say that you have two classes: com.javaranch.Foo and com.javaranch.Bar. If each of these is in a separate bundle, then when OSGi tries to satisfy a package import for com.javaranch, it will find one of them, and stop looking. So, the bundle(s) that imports com.javaranch will only get Foo or Bar, but not both.

This sounds kind of a bug to me. Is it a bug? Have OSGi folks any plan to fix this problem?

Craig Walls wrote:
There are two ways to fix this: If nothing else in your app depends on Lucene, then you could wrap the Compass JAR and embed Lucene within it (I show how to do this exact thing in the book). Or, you could wrap Compass and use Require-Bundle: to specify the Lucene dependency in Compass' MANIFEST.MF.

I'm not sure what you mean by "wrap". Do you mean open the Compass JAR and modify it?

[Craig Walls]

Kengkaj Sathianpantarit wrote:This sounds kind of a bug to me. Is it a bug? Have OSGi folks any plan to fix this problem?

No, not a bug...as designed. Split packages break modularity and are considered bad form. A properly laid out module shouldn't share packages with another module. Sure...everyone does it. But that doesn't mean that it's a good idea.

I'm not sure what you mean by "wrap". Do you mean open the Compass JAR and modify it?

"Wrap" generally means one of two things: Either cracking open the JAR and modifying the manifest *OR* creating a new bundle JAR with the wrapped JAR embedded inside of it. Both are legitimate ways of turning a regular JAR into an OSGi bundle. In either event, it's bad form for a developer to do this work manually. That's why I recommend one of those tools to do it for you (to eliminate human error when creating the new bundle JAR).