Contribute to the DSpace Development Fund

The newly established DSpace Development Fund supports the development of new features prioritized by DSpace Governance. For a list of planned features see the fund wiki page.

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 2 Next »

Definition of Asynchronous Release

Asynchronous Release: Asynchronous Release is change in the DSpace release process and version numbering process on modules within the DSpace trunk to allow more flexibility adding prebuilt Addon modules into DSpace.

Goals

The primary goal of Async release is to break the the authoritative grip that dspace-parent has on the version assignment and dependencyManagement in the DSpace trunk modules such that:

  1. 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
  2. Make a packaged release of DSpace that includes a combination of Trunk and Module projects. 
  3. 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.
  4. Allow immediate consumption of minor maintenance releases of DSpace modules without requiring major new releases and marketing or reliance on SNAPSHOT builds.

Requirements

  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: 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.

Technical Approach

  1. move all project that use dspace-parent to use dspace-pom
  2. move all versions identified in dependencyManagement into individual pom.xml where the dependency is required.
  3. Use dependencyManagement in dspace/pom.xml to control dependencies used in a local build
  4. Adjust dspace/modules/pom.xml to use dspace/pom.xml as parent
  5. Create DSpace "dspace/modules/cli" module that represents the assembly point for "dspace-cli" requirements.

Next Steps

  • Push a patch for the prototype into the JIRA for DSpace and get feedback from the committers group on the refactorings.
  • No labels

All content on the LYRASIS Wiki is licensed under the CC BY (Attribution) license, unless otherwise noted.