Preface

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.