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

This proposal is centerd around coninuing an effort to break apart the exisitng core DSpace modules to support further modularity. Firstly I will present the problem.

...

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 core

• 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"

Refactor DSpace ConfigurationManager to use Configuration Service.

This proposal is centerd around coninuing an effort to break apart the exisitng core DSpace modules to support further modularity. Firstly I will present the problem.

Refactor DSpace EventManager to use EventService

DSpace EventService is currently just processing usage events, it can also process all other events, EventManager should be dropped in favor of EventService , all usages of EventManager should be replaced with EventService and event Consumers rewritten to be EventListerners attached to the EventService.

Add DSpace Scheduling Services Add Quartz Job Scheduler as utility to manage asynchronous eventing in DSpace Services.

...