Application development has seen significant changes in the last years, moving towards a simpler, more agile, POJO-based programming model in order to keep a fast pace. Dependency injection and Aspect Oriented Programming, which were once bleeding edge ideas, are used on a daily basis by most developers to manage and simplify the complexity of their applications.

However, in terms of deployment, things have remained mainly unchanged. Even though code bases are divided into modules, whether logical, conceptual or physical, at runtime they are seen as one monolithic application in which, making a change (be it large or small), requires a restart. OSGi aims to change this by allowing applications to be divided into modules that can have different life cycles, dependencies and still exist as a whole.

Eclipse Gemini Blueprint (formerly Spring Dynamic Modules) focuses on integrating Spring Framework's powerful, non-invasive programming model and concepts with the dynamics and modularity of the OSGi platform. It allows transparent exporting and importing of OSGi services, life cycle management and control. Moreover, the Spring DM model was standardized in OSGi r4.2, in the form of the Blueprint Container for which Eclipse Gemini Blueprint serves as the reference implementation (RI).

While every effort has been made to ensure that this documentation is comprehensive and there are no errors, nevertheless some topics might require more explanation and some typos might have crept in. If you do spot any mistakes or even more serious errors and you can spare a few cycles during lunch, please do bring the error to the attention of the Eclipse Gemini Blueprint team by raising an issue. Thank you.