[
https://jira.duraspace.org/browse/DS-976?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Richard Rodgers updated DS-976:
-------------------------------
Status: Open (was: Received)
> Simple Asynchronous Add-on Facility for DSpace
> -----------------------------------------------
>
> Key: DS-976
> URL: https://jira.duraspace.org/browse/DS-976
> Project: DSpace
> Issue Type: New Feature
> Reporter: Richard Rodgers
> Assignee: Richard Rodgers
> Fix For: 1.8.0
>
>
> 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 ;))
>
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://jira.duraspace.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
------------------------------------------------------------------------------
BlackBerry® DevCon Americas, Oct. 18-20, San Francisco, CA
The must-attend event for mobile developers. Connect with experts.
Get tools for creating Super Apps. See the latest technologies.
Sessions, hands-on labs, demos & much more. Register early & save!
http://p.sf.net/sfu/rim-blackberry-1
_______________________________________________
Dspace-devel mailing list
Dspace-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dspace-devel
