[
https://jira.duraspace.org/browse/DS-976?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=21543#action_21543
]
Richard Rodgers commented on DS-976:
------------------------------------
Next, some comments on Mark D's comments (snippets copied):
>To be "endorsed", these should be released as binary artifacts into the the
>maven central repository (or other repo) with a formal release version number,
>not copied as source into a local directory. One could copy the source
>locally, but >that should be a source build process (good for developers), not
>the default "installing an addon" process (good for admins). In the original
>Asynchronous release process, all addon modules would have binary releases.
Yes, I should make clear that nothing in what I'm proposing should *require* or
even *prefer* that the add-on include the source - it can just refer to a
binary published artifact as you say. In fact, if in the interest of time we
wanted to simplify, I'd vote that 'published binary' be the first use case to
run with. I just wanted to indicate generally that the benefits of being able
to customize would extend to add-on code, and that a 'best practice' for add-on
distributors be to also offer a source version, just like DSpace itself does.
>If folks would use the ConfigurationService, defaults can live in
>[addon-src]/src/main/resources/dspace/dspace/config-[addon].cfg and the
>service will load them off the classpath prior to those being overriden in the
>directory, so there is >only a need to copy configs there if they are wanting
>to customize them
OK, but in my initial set of use-cases, there was always such a need. I would
not call this 'customization', because that implies there is a working default
configuration. In the case of duracloud.cfg for example, there is no such thing:
there are no 'default' credentials one can use. I would call it 'site
configuration' or some such.
>1.) What are the changes it makes to the poms? dependencies, modules? Does it
>add any dependencies that are required to the various
>dspace/modules/*/pom.xml?
Only one pom is currently modified: that is dspace/addons/pom.xml which is an
exact analogue of dspace/modules/pom.xml - i.e. it is simple maven pom-package
project that exists only to declare modules.
The only change is to add a single element in this section:
<modules>
<module>addon-name</module> <-- this is added by addon plugin when add-on
passes verification
</modules>
It adds no dependencies elsewhere.
> 2.) Where do you run your maven addon:insertany? its not clear in your
> description
You run this from the 'dspace' directory, same as where one would run 'mvn
package' etc There is logic in the plugin to check where it gets invoked, and
only operates when maven is in the 'addons' directory.
I also have not bound it to a life-cycle phase, but that is tempting to
consider. If one did it right, you would never even need to run it, and our
build would silently just pick up any new add-ons and do the right thing....
I like the idea of the modes of operation you outline - binary, source, local,
published, etc. and could certainly work to nail down each of those use cases
better.
Remember, one of the main objectives here was to address Tim D's legitimate
concern that we not make installation of add-ons too 'technically daunting', so
I was just starting to explore ways to do this that eliminated end-user
fiddling of pom.xml files and the like. But it also should have the power and
flexibility you are getting at...
Thanks for the good insights
> 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
