Why make my project an OSGI bundle as opposed to a standard JAR package?

For what reasons would I want to make my project an OSGI bundle as opposed to just a standard JAR package? Does it only mak开发者_Go百科e sense if it is going to be used by an application that uses an OSGI framework (eg: Equinox/Eclipse)? Or is it also useful from a development point of view, ie: being able to easily reuse my OSGI bundle by other projects during Eclipse development?

OSGi provides support for modules, you could control the dependencies. Each module may include and exclude packages from other bundles. You can also replace bundles during runtime. Making a whole project a single bundle has none of these benefits. I would only wrap a jar like a jdbc driver as bundle if it is not available as an OSGi bundle. First check whether your project would have a benefit. Then identify which modules should be a bundle.

If your project is a public or open source library, then please do make it an OSGi bundle. This will be of great help to OSGi developers who may want to use your library.

On the other hand if your library is private then the benefits of OSGifying it are limited. Mostly it will be an advantage if you decide to adopt OSGi strategically later. You may also derive some benefit from the explicit dependencies, i.e. you can look into the bundle to work out exactly what it depends on.

There is no runtime cost of doing this. The OSGi data in the manifest is simply ignored by non-OSGi runtimes.

You will have to generate the OSGi manifest though as part of your build step. The best tool to use for this is Bnd, which can be easily integrated into any ANT build -- use it as a replacement for the "JAR" task. If you are building with Maven, then use the Maven Bundle Plugin (which uses Bnd internally).

This is useful only if it's going to be used from within an OSGi container as you mentioned.

If you are searching an answer on why it is useful in general is something you can find a lot just by googling - start from Wikipedia:

• http://en.wikipedia.org/wiki/OSGi

In general, I'd say OSGi's main benefits are encapsulation/versioning, solving JAR hell and management provided by the framework, which may or may not be interesting to you depending on your project.

I definitively suggest reading about OSGi if you haven't already - it's very interesting technology. I would suggest reading Neil Bartlett's articles on EclipseZone - this is the first one:

• http://www.eclipsezone.com/eclipse/forums/t90365.html

There are a bunch of them, so google them - very interesting read, which will also give you an idea whether this is something you should consider.

SpringSource is a big proponent of OSGi, so it's worth taking a look there, too:

• http://www.springsource.org/osgi

If you ever plan on using it in an OSGi context then you might as well make it a bundle. I don't know that there are any negative affects to making it a bundle, whereas if you don't make it a bundle and find out later on that you need it to be then you may have to go back and fix it. Aside from that I personally don't know of anything other than OSGi which uses the manifest meta information - but like I said; I don't think it will hurt.

OSGIfying a project will allow OSGI to be used for dependency management in Eclipse instead of the standard Eclipse project build mechanism, or an external dependency management tool such as Ivy or Maven. Making a project into an OSGI bundle allows you to express that project's package dependencies as bundle dependencies (if a bundle exists for the package dependency) which will be handled by the OSGI framework instead of those other mechanisms (standard Eclipse project build/Ivy/Maven).

Standard Eclipse project dependencies are established by specifying other projects and libraries on your project's build path. Converting to OSGI would replace your build path references with MANIFEST.MF import-package or required-bundles declarations.

Advantages of using OSGI for dependency management over the standard eclipse mechanism are:

• re-export dependences: your bundle can re-export their dependent packages which means code relying on your bundle doesn't also have to rely on your bundle's dependants if it also uses them
• version management: so you can specify the minimum and maximum expected version of a dependency.

See also Should I use Eclipse plug-ins (or OSGi Bundles) as a plain dependency management tool?