Page History

...

previous path	new path under http://scm.dspace.org/svn/repo/modules/Image Removed
http://scm.dspace.org/svn/repo/dspace/trunk/dspace-apiImage Removed	modules/dspace-api/trunk
http://scm.dspace.org/svn/repo/dspace/trunk/dspace-xmluiImage Removed	modules/dspace-xmlui/trunk
http://scm.dspace.org/svn/repo/dspace/trunk/dspace-jspuiImage Removed	modules/dspace-jspui/trunk
http://scm.dspace.org/svn/repo/dspace/trunk/dspace-oaiImage Removed	modules/dspace-oai/trunk
http://scm.dspace.org/svn/repo/dspace/trunk/dspace-swordImage Removed	modules/dspace-sword/trunk
http://scm.dspace.org/svn/repo/dspace/trunk/dspace-lniImage Removed	modules/dspace-lni/trunk

Adopt usage of dspace-pom and eliminate dspace-parent

New Maven POM projects exist for DSpace in the modules directory, these pom eliminate a bottleneck in the dependency mechanism defined in the dspace-parent pom in favor of allowing individual projects manage their dependency versions. It is released separately from the DSpace release process so that it can be utilized before the official release to base new modules on.

http://scm.dspace.org/svn/repo/modules/dspace-pom/tags/

Doing this increases the flexibility to define and override dependency versions used when customizing DSpace instances in the wild. And depending on this pom provides all the basic details for the build and release process of maven without forcing specific dependencies onto the components that use it.

Promote using the non-source release

If users work with the source release as the default, it defeats the whole process of providing a build and development process that is modular. end users still customize the classes directly and still attempt to alter core classes that they should not be touching.

Working with a binary release clarifies which calles should be allowed to be overridden in DSpace and promotes using configuration and pluggin interfaces in DSpace over modifying and recompiling code in place. Moving the dspace-xxx modules out of trunk further enhances this dichotomy. And allows for a clear separation of User customization and DSpace development direction.

Refactor DSpace API into separate modules where appropriate

...

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

...