[
https://jira.duraspace.org/browse/DS-976?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=21518#action_21518
]
Mark Diggory commented on DS-976:
---------------------------------
I'll try to review this as best I can to outline where my concerns are with the
design, I'm not really getting it. Are you saying that we need to create
dspace/modules/addons and put any new addon code in there? what about if I
have addons that only xmlui will depend on or which only jspui will depend on,
does this support any of that?
1.) Need this to already work with addons that are released to maven central or
installed into local maven repo, I should be able to include the addon as a
dependency into the build without needing its source or a directory in modules.
this means only adding it as a dependency to the dspace/modules/[module] that
needs to have it.
2.) The current strategy is to use dspace-pom (the latest being 10) for any
addons, this allows the addon and DSpace to be "asynchronous" thus addon may
use any version of DSpace (IE by making dspace-api:1.7.2:jar a provided
dependency as you have) then the addon can be installed with 1.6x, 1.7x, 1.8.x
as long as theres compatibility. thus there is no requirement for a
pre-released dspace-parent 1.8.0 to write a addon that will work with dspace
1.8.0 in the future.
3.) I'm not sure what the "configuration changes" are your identifying in your
instructions?
4.) Rather than writing a pom template, please look at the Maven artifact that
already exists for dspace addons here, I'm sure you see rather quickly that we
can bootstrap an addon project from maven for the user. Addressing (2) assures
that we don't need to release archetypes every time we release a version of
DSpace. Likewise, in (3) running archetype generate to create a fresh addon
project in dspace/modules automatically adds it to the modules section of the
dspace/modules, thus as you can see the archtype plugin is pretty powerful for
new projects, but still does not address installing addons into individual
webapplications separately.
http://scm.dspace.org/svn/repo/tools/maven/dspace-addon-archetype/
http://scm.dspace.org/svn/repo/tools/maven/dspace-xmlui-archetype/
To be honest, isn't this still more complex than
1.) create a maven project in [dspace-src]/dspace/modules/[addon] using
archetype
2.) Add it as a dependency to dspace/pom.xml and whatever
dspace/modules/[addon]/pom.xml
note, my comments about creating a separate "cli" project in dspace/modules
simplifies the above to:
1.) create a maven project in [dspace-src]/dspace/modules/[addon] using
archetype
2.) Add it as a dependency to whatever dspace/modules/[addon]/pom.xml
In fact, if we wrote a more advanced archetype for addons, we might be able to
automate which addons the new project should be associated with and add the
dependencies only to those.
Finally, if we continue on this vein for your proposed plugin, the plugin might
take parameters (maven coordinates) for an addon that should be added and the
apps it should be added to "xmlui, cli, sword" and just adjust the dependencies
on those projects. This would be the most useful mechanism I can think of to
install a binary released addon into dspace from maven central.
> 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
