[
https://jira.duraspace.org/browse/DS-976?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=21533#action_21533
]
Richard Rodgers commented on DS-976:
------------------------------------
Great comments Mark & Tim. To preserve the conversational thread, I'll respond
first to Tim, then Mark, so bear with me...
Tim's re-quoted with inline remarks:
1. I'm also slightly confused about the process here. Is the 'addon' directory
you talk about in [dspace-src]/dspace/addon/ (I'm assuming so, but just wanted
to verify)? How does it differ from the existing [dspace-src]/dspace/modules/
(or is it really just the same concept, but you are specifically wanting the
'addons' to be separate from the out-of-the-box 'modules'?)
You describe it correctly - same concept (in fact the parent pom which has
<module>modules</module> just adds an element <module>addons</module>). From
the maven perspective they are similar, I just wanted to 'sandbox' or isolate
them for special treatment (via validation, or removal if desired, etc), since
they represent site-specific choices, not dspace architectural choices...
2. I'd agree with mdiggory that it would be nice if it's possible to just
install add-ons via Maven. So, seeing if we could avoid having to search out
and download each add-on source zip separately (if possible). Since you are
already dynamically modifying the addons/pom.xml file, it seems it should be
possible to insert in a new '<dependency>' tag so that a particular Addon could
be installed directly from Maven central. (This would be similar to mdiggory's
idea of passing in maven coordinates, and even potentially which apps it would
be installed into)
I'd be happy to go in this direction. The only reason I didn't focus on it at
first was that all my initial use cases involved add-ons that had *required
locally edited resources* (mainly configuration files that need to placed in
the source tree). There is no reason why one could not imagine a 'pure' add-on
(say a set of jars or static resources), that could be identified via maven
coordinates, and let maven do all the fetching....
3. I like the validation restrictions you impose, except for one. I don't think
we should force all addons to have a GroupID of 'org.dspace.addons'. If we want
third-party groups to be able to create & make available their own DSpace
Addons, then we need to also allow those third parties to be able to release
their addons to Maven Central (if they wanted to). Only DSpace Committers can
release Maven modules with 'org.dspace' GroupIDs to Maven Central. So, this
would be accidentally creating a roadblock for third-party addons. I don't
think we should force all addons to be approved & released by the Committers.
Rather, individual institutions should be allowed to create their own addons
and share them with everyone else. So, I'd rather remove that GroupID
restriction. Instead, we could change the required property to something like:
<properties>
<dspace.addon.type>fallen-fruit</dspace.addon.type>
<dspace.addon.version>1.0</dspace.addon.version>
</properties>
That way we are checking for properties that specifically state this is a
*dspace* addon, and it gives us info about the type of addon & version of addon
this reports to be.
This is quite true, and I agree completely that we want to encourage
third-party add-on authoring. The only reason I imposed this limitation is due
to an obscure technical detail about how the maven assembly process filters by
coordinates (i.e. groupId, artifactId, etc) - it was an easy way to isolate and
treat add-ons during assembly. There are doubtless other ways to attack that.
Overall, I do think it looks like a good first draft. It would be worth someone
investigating mdiggory's ideas around archetypes, just to see if they make
things easier. But, obviously we can also improve on this model as we go
forward as well.
Archtypes would be great to offer - I did not mean the template as a
counter-suggestion - just an easy way to read all the restrictions in context
while we kick around these ideas...
Thanks
> 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
>
> Attachments: addon-pom-template.xml, addon-tool.tar
>
>
> 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
------------------------------------------------------------------------------
uberSVN's rich system and user administration capabilities and model
configuration take the hassle out of deploying and managing Subversion and
the tools developers use with it. Learn more about uberSVN and get a free
download at: http://p.sf.net/sfu/wandisco-dev2dev
_______________________________________________
Dspace-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/dspace-devel
