With the RC2 of SpringSource’s dm Server the OSGi development in Java will gain even more momentum. There are two camps of developers: one hates OSGi and the other loves it.
The reasons for hate include steep learning curve, difficulty in migrating existing applications and complexity of deployment. The first two reasons are understandable. Our SpringSource Application Platform in Action book will help with the first one and the dm Server will do an excellent job in making the migration as painless as possible. The third complaint — complexity of deployment — is not so clearly cut. If you currently need to deploy multiple versions of the same service at the same time, chances are that the complexity of your application is far greater than the complexity if equivalent OSGi-based application. In most cases, programmers actually refer to deploying a new version of a particular class or jar. But they do not want the new version to be available at the same time as the old one. Essentially, once the new version is out, the old version is lost. It is the typical update & pray scenario. You can obviously do the same with OSGi bundles. There’s nothing stopping you from updating a bundle whilst keeping its version number. OSGi is not obtrusive at all in this respect!
Similar thing happened to .NET assemblies: the assemblies can include a version number and .NET type identification includes the class name, the assembly and optionally a version number. Most systems use only the simple type identification, without the version number. The users of the .NET Framework have thrown away the versioning control in favour of trivial deployment and risk of problems.
Change of thinking
What we need is a shift in thinking: you can still continue with the big bang deployment, even in the OSGi world. You should, however, try to make full use of the features of the OSGi’s execution environment. This will pave the way towards easily maintainable applications in the future.