Lessons learned
In our work on applying the adaptation pattern to the existing application platform we have been faced with noticeable problems and results not obvious at first sight.

1.  Java as a language makes it easy for developers to start and produce results in a relatively fast manner. Unfortunately this doesn't imply that the code created fulfills certain quality criteria called the best practices (see, for instance, [12], [13] and [14]). On top of that, component based development in general, and OSGi in particular, assumes that application developers at least follow the best practices. This creates the necessity to rearrange and, sometimes, modify parts of the legacy Java code or provide a wrapper to compensate for the shortcomings introduced by that code. Our experience shows that most of the legacy code requires at least minor changes and can't be 'bundle-ized' as it is.
2.  Even if the application framework is based on logical components and claims to be component oriented, its component model may be flawed. Unless the componentization is enforced with a proper code separation and the isolation level guaranteed by class loaders, like in OSGi, the logical components still do not adhere to the real definition (see ?[19]). Very common examples of component model flaws are circular dependencies on the package or even JAR level.
3.  Although OSGi introduces a very potent componentization platform, the focus is on structuring Java classes. Resource centric frameworks, like UIMA, need to create their own infrastructure to compensate for shortcomings created by their resource oriented view. Many shortcomings are not originated by OSGi, but are a result of the Java limitations. For example, the JVM limits the number of custom URL handlers that can be specified for a single protocol to merely one, a similar problem exists with the java.sql. package, which assumes a global implementation instead of a federation of different implementations and versions, another problem is that the protection of the core framework from malicious code introduced by third party components goes beyond the capabilities of Java runtime and the SecurityManager, just to name a few.
4.  Based on the nature of OSGi, every global entity such as a distinct class shared among your application bundles might become a real problem, unless these entities are not treated as first class citizens. Examples of such entities are JCas cover classes in UIMA, which are automatically generated by the frameworks and usually packaged with each analytic component. If such classes are not externalized and referenced as first class citizens, multiple identical classes with different class loaders may appear in the class path. In plain Java, this is no problem, because the application usually has only one class loader. In OSGi, however, this will cause a ClassCastException if one component needs to cast a class, already instantiated by a class loader not compatible with this component's class loader. To avoid problems in OSGi container, these classes have to be isolated in separate bundles and made available as entities of collaboration for all component developers.

Conclusion
Looking from a bird eye view at our approach, we can conclude that we achieved our goal by adding a thin layer of abstraction to hide all the complexity of the OSGi adaptation from the application and component developers. This layer allows both kinds of developers to switch to a component based environment with minimal change of the current code and almost no change in the programming model. However, if one wants to benefit from all the features introduced by this new componentization approach, especially the dynamism and updatability, a shift in the application programming paradigm towards an asynchronous event based application model is essential. Furthermore, component reusability is not guaranteed by simply dividing and packaging an application in several components. We are facing problems here, which can not be easily solved by following coding best practices. A deep understanding of the problem and the ability to abstract from a concrete problem to a general solution is crucial in defining reusable software system components. Problems like the configurability and customization of resources outside of the application framework API, as well as the version management constraints are also left open in this article and need to be addressed separately.

References
[1] OSGi Technology,
www.osgi.org/osgi_technology/?section=2
[2] JSR 277: Java Module System,
http://jcp.org/en/jsr/detail?id=291
[3] JSR 291: Dynamic Component Support for Java SE,
www.jcp.org/en/jsr/detail?id=291
[4] OSGi Projects @ JavaOne 2006,
www2.osgi.org/div/massive.ppt
[5] About the OSGi Service Platform,
www.osgi.org/documents/collateral/TechnicalWhitePaper2005osgi-sp-overview.pdf
[6] UIMA @ IBM Research,
www.research.ibm.com/UIMA/
[7] UIMA @ Wikipedia,
http://en.wikipedia.org/wiki/Uima
[8] Ferrucci, D., Lally, A., "UIMA: an architectural approach to unstructured information processing in the corporate research environment", Natural Language Engineering, Volume 10 , Issue 3-4 (Sep 2004), pp. 327-348, Cambridge University Press, New York, NY, USA, 2004, ISBN: 1351-3249
[9] Goetz, T., Suhre, O., "Design and Implementation of the UIMA Common Analysis System", IBM Systems Journal, v.43, # 3, 2004, pp.476-489, www.research.ibm.com/journal/sj/433/gotz.html
[10] Ferrucci, D., Lally, A., "Building an example application with the Unstructured Information Management Architecture", IBM Systems Journal, v.43, # 3, 2004, pp.455-475,
www.research.ibm.com/journal/sj/433/ferrucci.html
[11] Schor, M., "An Effective, Java-Friendly Interface to the CAS", Research Report RC23176, IBM T.J. Watson Research Center, Yorktown Heights, NY, 2004,
http://domino.research.ibm.com/library/cyberdig.nsf/1e4115aea78b6e7 c85256b360066f0d4/d55875841121943e85256e78004bd826?OpenDocument
[12] Gregory Brail, John Wells: "The Good, Bad, and Ugly of OSGi: What we learned building the mSA Backplane",
EclipseCon 2007, www.eclipsecon.org/2007/index.php?page=sub/&id=3859
[13] BJ Hargrave, Peter Kriens: "OSGi Best Practices", JavaOne 2007,
http://developers.sun.com/learning/javaoneonline/j1sessn.jsp?sessn=TS-1419&yr=2007&track=3
[14] Jahn, Mirko: OSGi applied, Teil 3: OSGi best practices. In: JavaMagazin (2007), 9, P. 97-102
[15] Nash, M., "The Java Framework Landscape", http://www.developer.com/design/article.php/3617156
[16] Application Framework, http://en.wikipedia.org/wiki/Application_framework
[17] Kozakov, L., Jahn, M., Doganata, Y., "OSGi Enablement in UIMA Framework", IBM Research Report RC24308, July 2007,
http://domino.research.ibm.com/library/cyberdig.nsf/1e4115aea78b6e 7c85256b360066f0d4/c77885d8151bed8d8525731c0067d980?OpenDocument
[18] Dynamic Module Enabler for Unstructured Information Management Architecture Analytics, IBM alphaWorks, June 2007,
www.alphaworks.ibm.com/tech/dmeuima
[19] Szyperski, C. et al., Component Software - Beyond Object-Oriented Programming, 2003, ISBN: 0-201-74572-0
[20] Jahn, M., "OSGi applied, Teil 1: Komponentisierung in Java", In: JavaMagazin (2007), 8, P. 54-59
[21] Fowler, M., "Inversion of Control Containers and the Dependency Injection pattern",
www.martinfowler.com/articles/injection.html
[22] IBM WebSphere Application Server V6.1: Componentization Overview,
http://publib.boulder.ibm.com/infocenter/ieduasst/v1r1m0/ index.jsp?topic=/com.ibm.iea.was_v6/was/6.1/Architecture/WASv61_Componentization/player.html
[23] Spring-OSGi,
www.springframework.org/