Child pages
  • The Unbearable Heaviness of Shared (Component Manager Directions)
Skip to end of metadata
Go to start of metadata

This BOF will discuss requirements and roadmaps for the Sakai Component manager, in terms of making it easier to work with for developers, offer more options for deployers, and to move gradually towards more standard deployment environments.
Things on the table - possibilities, timings, strategies for a move to OSGi (Eclipse Equinox/Apache Felix?). Use of Spring contexts, role of Spring-OSGi. Any intermediate strategies, transition plans, incremental working.

  • No labels


  1. Great idea for a BOF! I've thinking about the possibility of using Spring-OSGi as the foundation for a new approach to the Component Manager as well. It brings up some interesting opportunities:

    • Is this perhaps the basis for starting a Sakai 3.0 architecture?
    • Can we loosen the implicit tight-coupling between (and within) many of the services provided by the Component Manager?

    Of course, this does turn into another project to improve the plumbing and not one that actually makes Sakai better for teaching and learning...

  2. Well, I work in a classroom building with poor plumbing, and I can tell you it's mighty distracting sometimes.... (smile)

    We may also touch on some shorter term, high payback changes which would help a team get familiar with working together in that part of the framework. Making properties loading more flexible would be a big help for large institutions and for integration testing, and I don't think it's a particularly big task once we have buy-in. As a more ambitious interim step, adding some centralized component management could make it easier for institutions to deploy binaries and avoid editing source and rebuilding.