Uploaded image for project: 'DSpace'
  1. DSpace
  2. DS-976

Simple Asynchronous Add-on Facility for DSpace



    • Type: New Feature
    • Status: Accepted / Claimed (View Workflow)
    • Priority: Minor
    • Resolution: Unresolved
    • Fix Version/s: None
    • Component/s: None
    • Labels:
    • Attachments:
    • Comments:
    • Documentation Status:


      Placeholder for design ideas, proposals and discussions around supporting an asynchronous release process for add-ons, which are functional extensions to DSpace.

      Motivation: in addition to long-standing wishes to add greater flexibility, modularity and extensibility to DSpace, there is an immediate need to provide a low-risk, lightweight way to distribute the AIP backup & restore add-on (including DuraCloud-backed storage) which has been developed to be available for, and compatible with, the 1.8 release.

      I believe given the short time-frame and other resource constraints, it makes good sense to look at very simple designs that address these initial sets of add-on use-cases, but which hold the potential to be elaborated to accommodate more complex use-cases in the future (or at the very least, do not preclude different approaches later if needed). Therefore (to lean on a very tired metaphor), we should look for 'low-hanging fruit' by leveraging our existing build and deployment infrastructure as much as possible. In fact, I would lower the bar even further, and characterize the first system as 'fallen fruit' - essentially seeing what we can scavenge using current tools and practices. With that preamble, here are some initial definitions, scope considerations, design ideas, etc for a FF asynch add-on mechanism:

      (1) Definition/scope of a FF add-on:

      An add-on is a collection of code and discrete resources that extends DSpace functionality when added to a runtime (deployed) installation.
      Add-on source code can reside in any legal package that does not conflict with base DSpace code, or known published 3rd party code. The usual best practices/conventions should prevent collisions.
      An add-on must possess a maven pom compatible with current DSpace maven requirements in order to integrate with current build and deployment processes.
      An add-on must be available in a standard archive (zip, tar.gz, etc) containing any code and resources, together with the maven pom. That is, it must resemble an ordinary maven project.
      An add-on's code may be available in binary form (by pom reference) only if it published in a designated maven repository. Source code distributions of add-ons are optional, but it is desirable to have both source and binary available, as current DSpace practice is for the packaged releases.
      Add-on resources will be limited to a subset of those currently found in /dspace: specifically only files that reside in /bin and /config
      A resource is discrete if it does not require a 'merge' into an existing resource. Thus, an add-on will not contain information to perform edits, inserts, etc into other resources - these edits may in fact be required, but are regarded as out of scope for automated add-on operation. New configuration files, e.g. under config/modules, are good examples of discrete resources.
      An add-on will not require any database schema changes. Of course, this need is legitimate, but will not be supported initially.

      (2) FF Add-on life-cycle considerations

      An add-on will be installed into an existing (source) DSpace installation, rather than to a specific runtime deployment of same. As such, it can be deployed to many locations.
      Although possible, uninstall of an add-on is out-of scope.
      It will be possible to determine what add-ons are present in a system by examining the DSpace source tree - visibility in the runtime/Admin UI, etc is currently out-of scope.

      (3) A straw-man for add-on process:

      Current DSpace (scratch) installation has essentially 4 stages:

      (1) Download & stage (unzip)
      (2) Configure (manual process)
      (3) Prepare (which typically means maven compile and/or package)
      (4) Deploy* (usually via ant fresh_install or update, and copies to Tomcat, etc) - * indicates multiple targets

      I would propose that the installation of an add-on have this exact sequence:

      (1) Add-ons (as noted above) look like installations
      (2) Many add-ons require separate configuration, so we have to provide for this step
      (3) Prepare would look similar, but would also have to manage transfer of resource files
      (4) Deploy might always just be an 'ant update'

      This is just a rough initial set of thoughts - comments welcome (I see mdiggory already has some )




            rrodgers Richard Rodgers
            rrodgers Richard Rodgers
            0 Vote for this issue
            1 Start watching this issue