Page History

...

Make the build in the DSpace Modules Source Tree dependent on a specific dspace-api and dspace-xmlui-api versions. Specifically, dspace-statistics and dspace-discovery
Make a packaged release of DSpace that includes a combination of Trunk and Module projects.
More easily package releases of DSpace cyclically while allowing minor updates of core modules to occur more often, to easily provide a minor update path for DSpace.
Allow immediate consumption of minor maintenance releases of DSpace modules without requiring major new releases and marketing or reliance on SNAPSHOT builds.

Requirements

dspace-parent is removed from the project, all dependency management is maintained in the modules that are using those dependencies, a dependency management section may be added to dspace/pom.xml or dspace/modules/pom.xml to support overriding the default dependencies identified in dspace-api, dspace,xmlui-api etc.
dspace-api should be released with a separate version number separate the general DSpace 1.x.x release. For instance, taking on the idea of using Single digit version numbers for releases, We would promote using 1.8.0 for a release of dspace-api while using 8.0 for the release. (dspace-api-1.8.0.jar would be in dspace-release-8.0)
dspace-api should be separated into individual modules. The codebase should be evaluated to determine the extraction points, But strong candidates for pushing into separate packages are:
- dspace-core: containing org.dspace.plugin and org.dspace.core
- dspace-legacy-storage: containing org.dspace.storage.rdbms and org.dspace.storage.bitstore
- dspace-model: containing org.dspace.content and org.dspace.browse (until the circular dependency on Browse can be removed)
- dspace-app: Applications and addon support found in org.dspace.apps
- dspace-cli: A refactored ScriptLauncher that uses Service Manager to get Commands.

...