SummaryAt a face-to-face meeting in April 2009, the Fedora committers agreed to begin moving toward OSGi as a module framework for Fedora. Over the remainder of 2009, several of us gained experience with OSGi:
When the committers met in London in Feb 2010, we discussed what we have learned about OSGi and came to the conclusion that, while OSGi provides several capabilities that we still see as valuable (dynamic re-configuration, classloader isolation, and a standard module lifecycle), it has a significant learning curve and brings with it a new set of dependency management issues. We also noted that moving to a modern dependency injection framework would not be as difficult, nor necessarily incompatible with an eventual move to OSGi. So, rather than concentrating on "Moving to OSGi" as a goal in itself, we resolved to improve Fedora's modularity in other, more tractable ways, while using the knowledge we've gained over the last year to increase Fedora's "OSGi-Friendliness" over time. We have identified a few concrete steps we can take to move Fedora's Module Architecture forward:
Want to Help?Great! Please signal your interest by adding your name below, contributing to this wiki page, and participating in related discussions on the fedora-commons-developers mailing list. Lead: Chris Wilper Interested Contributors: Dan Davis, Andrew Woods, Asger Askov Blekinge OSGi FriendlinessWhat can we do to make Fedora more OSGi-friendly (ideally, without building in any runtime dependencies on OSGi)?
Dependency Injection FrameworkProblem StatementFedora's original Server and Module classes were designed in 2002, and provided a common way for major functional components ("modules") of the repository to be plugged in, configured, initialized, and stopped. Problems with the existing framework include:
Requirements
Non-requirementsThis work will NOT attempt to:
These capabilities may be added in the future, possibly with the help of OSGi. Framework ChoicePopular frameworks that support the dependency injection pattern include Spring, PicoContainer, and Guice. How do they compare? Several articles have been written comparing Spring and Guice, as well as all three. As many have pointed out, Spring and Guice are more than DI frameworks. For our purposes, we should consider the attributes of each that are most relevant to the problem at hand:
|