Page History

...

1. 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.
2. 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)
3. 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/dspace-core-api: containing Interfaces for Domain Model and Services centered on org.dspace.content, org.dspace.plugin and org.dspace.core (stored outside DSpace trunk)
   • *dspace-core/dspace-core-impl:  * containing implementations of DSpace above services,org.dspace.plugin and org.dspace.core, org.dspace.content and org.dspace.browse (until the circular dependency on Browse can be removed)
   • dspace-core/dspace-legacy-storage: containing org.dspace.storage.rdbms and org.dspace.storage.bitstore
   • dspace-core/dspace-legacy-app: Applications and addon support found in org.dspace.apps
   • dspace-core/dspace-cli: A refactored ScriptLauncher that uses Service Manager to get Commands.

...