Page History
...
- 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.
- 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"
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
Overview
Content Tools