Page History
...
Refactor DSpace API into separate modules where appropriate
DSpace API is a entangled mass of conflated functionality. It is highly recommended that DSpace API be separated apart in terms of functionality to support greater separation between content model, applications and utilities in. Proposed areas of functionality need further analysis but look like the following:
Why, because we cannot maintain modules independent of core that depend on a specific core release version and then release them as part of core. It may sound convoluted, but this is an example of what has happened with dspace-stats in DSpace 1.6.0. Our initial goal was to maintain the stats packages independently, depending on a specific release of DSpace services. Individual user interfaces would have still resided in the dspace-xmlui and dspace-jspui cores. But the goal was to exemplify module development occurring outside the core and easily being added into it forthe release process.
Why did this fail? This failed due to circular dependencies between dpace-statistics and dspace-api. This was something that the work in DSpace 2.0 sought to eliminate by allowing the creation of API separate from implementation that were not dependent on a central core with all the features in it. An example of this being successful is dspace-discovery. Where once it is finished, it should be only dependent on dspace-services and solr, just the coreeventually int he future it will not even be dependent on dspace-api.
DSpace API is a entangled mass of conflated functionality. It is highly recommended that DSpace API be separated apart in terms of functionality to support greater separation between content model, applications and utilities in. Proposed areas of functionality need further analysis but look like the following:
- Applications: DSpace Applications are generally found under the package http://scm.dspace.org/svn/repo/dspace/trunk/dspace-api/src/main/java/org/dspace/app/ org.dspace.app and generally other package should not be dependent on these. It is recommended that they be broken off where appropriate and repackaged individually (statistics, import, export, mediafilter, bulkexport, etc) The goal in separating these out is to promote development fo new applications without dependency on the dspace core release cycle and reduce the need for core releases to add application enhancements to DSpace.
- Core: DSpace Core is made up of http://scm.dspace.org/svn/repo/dspace/trunk/dspace-api/src/main/java/org/dspace/core/ core, http://scm.dspace.org/svn/repo/dspace/trunk/dspace-api/src/main/java/org/dspace/content content, http://scm.dspace.org/svn/repo/dspace/trunk/dspace-api/src/main/java/org/dspace/event event and a number of other packages, these packages should be reviewed with a dependency analysis and repackaging in to separate maven projects with separate release cycles will improve our ability to provide updates to these packages outside a "core" release cycle"
The ultimate goal in separating out this functionality it to get the core of DSpace clearly defined as a set of core Service API backed by an encapsulated implementation. DSpace Applications should only be dependent on the Services API defined and not the actual classes implementing the backend functionality.
Outlined below are some of the possible directions for refactoring once we begin this process of refactoring.
Refactor DSpace ConfigurationManager to use Configuration Service.
...