Page tree
Skip to end of metadata
Go to start of metadata

Overview

DSpace needs a clear definition of what constitutes a "DSpace module", so that third-parties can create, maintain and distribute their own "modules" as add-ons to DSpace. These third-party modules also need a way to be easily distributed and advertised via some form of "module registry". The registry would allow users to find and select third-party modules to install into their own DSpace, as they see fit.  DSpace would also need mechanisms to install, upgrade or uninstall individual modules. A "DSpace module" would also need a specific version number, and a dependency definition (e.g. "requires DSpace 6.0 or above").

Use Cases / Needs

  • Define a family of specifications/interfaces for functional extensions to 'core' DSpace ( working title: 'modules'), and refactor existing bundled code to conform to new model (if appropriate/cost-effective)
  • Provide infrastructure/tools for a module registry, where users can discover, and install modular extensions. Likely include both modules maintained by committers and community contributions.
  • End goal would be to find a way to modularize components of DSpace so that institutions can mix & match modules to meet their local needs.
    • Certain modules would come "out-of-the-box" (the ones most folks will want to use by default & that make DSpace easy to get started with). Some of these may be mandatory (if DSpace really needs them to function well), while others are just "recommended"
    • Additional modules would be available via the module registry.

Planning Phase - Prototyping and Selecting a Framework

Timeline is TBD based on establishment of a Module Framework Team

  • Establish a dedicated "Module Framework" technical team to prototype potential platforms. This team will consist of volunteer or "donated" development resources
  • Define a list of possible "module framework" options to analyze (paying special attention to similar functionality in other Java-based projects)
  • Prototype at least one "module framework", along with a basic ("Hello World" like) sample module for testing / verification
    • If multiple feasible options exist, more than one framework should be prototyped, implementing the same sample module.

Development Phase

details needed

  • No labels