[
https://jira.duraspace.org/browse/DS-976?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=21409#action_21409
]
Mark Diggory edited comment on DS-976 at 8/2/11 8:20 PM:
---------------------------------------------------------
One of the first comments, I would like to see a clear specification of what an
Addon is, which we have been working on for some time. If this is a design
dialog, it should reflect the past activities goals and requirements as well.
Original Asynchronous Release Requirements.
1.) Addons are jar or war projects that contribute a library + dependencies and
or a webapplication overlay to the maven build process
2.) Addons should avoid classpath overrides of existing DSpace core classes.
3.) Addons need to be added to the maven build process (so that transitive
dependency analysis and replicable builds are possible).
This said, all of DSpace and any additional libraries are a modular set of
maven projects, dspace-services represents the foundation of modularity for the
next generation of DSpace and as such is a set of "conventions" on hwere to
place default configuration and spring configuration files such that DSpace can
find them int he jars/wars and enable the addon via the service manager. Thus
at this time, Maven + the Service Manager represent the core tools we have to
support our needs when creating addons for DSpace that only require the
addition of the dependency.
Per our meeting yesterday, I made the following recommendations for clearly
defining "levels" whereby a maven plugin might insert dependencies into the
build poms. They were:
a.) restructure the "cli" library dependencies inserted into lib to be a
separate modules project, see the following for an example, the goal is to make
it the case that one addition to dspace/modules/pom.xml will support the
addition of a dependency jar to all modules projects inheriting the maven pom
http://scm.dspace.org/svn/repo/dspace/branches/dspace-async-release/dspace/modules/
b.) Define rules for adding to modules, cli, xmlui, etc such that it can be
clearly documented how to add addons to dspace in a clean and predictable
manner. Note for instance, we probibly do not want to have dependencies we add
to modules/pom.xml showing up in the solr webapp. So it is probibly wise to
drop its inheriting from the modules parent.
http://scm.dspace.org/svn/repo/dspace/trunk/dspace/modules/solr/pom.xml
Alternatively:
c.) We could add an empty "api" or "common" jar project that supplies
dependencies for all "dspace" webapplications excluding "solr", additions to
the dependencies of this project would be transitively associated and built
into all other projects.
-----
The most dead simple mechanism to support asynchronous addition of addons after
the release (those that might be considered "supported") would be to add it as
a comment in the pom and give instructions on how to turn it on in the
documentation by uncommenting the clause.
-----
This said, I highly recommend that if a simplified approach to achieving true
asynchronous build/install process for addons is to be explored (ie, the
insertion of addons into the deployment directory of DSpace independent of the
main maven/ant build, that we should be clearly identifying the requirements
and targets roadmap that will support a preexisting stable solution for
providing such addons to DSpace. A few important requirements I can think of:
1.) Any mechanism to register additional addons into the deployment outside of
the normal dspace build process should not destabilize current build practices
and the use of maven poms to define addons and the ability to use this
mechanism for replicable builds and for debugging purposes.
2.) Any mechanism that will alter the contents of the lib, WEB-INF lib should
assure that dependencies from the original build are not removed or shaded on
the classpath
3.) Any attempts to complete webapplication overlays or similar overlays on the
configuration/etc directories should be "undoable" such that the addon can
easily be removed from the deployment easily.
I suggest that we should probably limit the initial work of "supplying addons
after deployment" to only refer to addon jars with no other dependencies
(meaning that all dependencies already present in DSpace should/would be marked
as "provided" and that the versions of those dependencies should always be
aligned with those already in force within DSpace. This would eliminate a
great deal of transitive dependency processing requirements and limit changes
to only be additions to the lib and/or WEB-INF/lib directories.
Likewise, I recommend not approaching webapplication overlaying and/or
alteration of existing configuration files in this process. But, if overlaying
were to be provided, it should be limited to only additions.
----
An approach to doing this might be possible using maven, assemblies and the
assembly process to write a deployment to a target ${dspace.dir}/lib,
${dspace.dir/webapps/xmlui/WEB-INF/lib and so on. The current release process
utilizes these (albiet we are working to shift to move the release assemblies
back into the source tree).
http://scm.dspace.org/svn/repo/tools/maven/dspace-assembly-plugin/trunk/src/main/resources/assemblies/
was (Author: mdiggory):
One of the first comments, I would like to see a clear specification of
what an Addon is, which we have been working on for some time. If this is a
design dialog, it should reflect the past activities goals and requirements as
well.
Original Asynchronous Release Requirements.
1.) Addons are jar or war projects that contribute a library + dependencies and
or a webapplication overlay to the maven build process
2.) Addons should avoid classpath overrides of existing DSpace core classes.
3.) Addons need to be added to the maven build process (so that transitive
dependency analysis and replicable builds are possible).
This said, all of DSpace and any additional libraries are a modular set of
maven projects, dspace-services represents the foundation of modularity for the
next generation of DSpace and as such is a set of "conventions" on hwere to
place default configuration and spring configuration files such that DSpace can
find them int he jars/wars and enable the addon via the service manager. Thus
at this time, Maven + the Service Manager represent the core tools we have to
support our needs when creating addons for DSpace that only require the
addition of the dependency.
Per our meeting yesterday, I made the following recommendations for clearly
defining "levels" whereby a maven plugin might insert dependencies into the
build poms. They were:
a.) restructure the "cli" library dependencies inserted into lib to be a
separate modules project, see the following for an example, the goal is to make
it the case that one addition to dspace/modules/pom.xml will support the
addition of a dependency jar to all modules projects inheriting the maven pom
http://scm.dspace.org/svn/repo/dspace/branches/dspace-async-release/dspace/modules/
b.) The most dead simple mechanism to give a reference that a module could be
added to dspace for build purposes would be to add it as a comment in the pom
and give instructions on how to turn it on in the documentation by uncommenting
the clause.
This said, I highly recommend that if a simplified approach to achieving true
asynchronous build/install process for addons is to be explored (ie, the
insertion of addons into the deployment directory of DSpace independent of the
main maven/ant build, that we should be clearly identifying the requirements
and targets roadmap that will support a preexisting stable solution for
providing such addons to DSpace. A few important requirements I can think of:
1.) Any mechanism to register additional addons into the deployment outside of
the normal dspace build process should not destabilize current build practices
and the use of maven poms to define addons and the ability to use this
mechanism for replicable builds and for debugging purposes.
2.) Any mechanism that will alter the contents of the lib, WEB-INF lib should
assure that dependencies from the original build are not removed or shaded on
the classpath
3.) Any attempts to complete webapplication overlays or similar overlays on the
configuration/etc directories should be "undoable" such that the addon can
easily be removed from the deployment easily.
I suggest that we should probably limit the initial work of "supplying addons
after deployment" to only refer to addon jars with no other dependencies
(meaning that all dependencies already present in DSpace should/would be marked
as "provided" and that the versions of those dependencies should always be
aligned with those already in force within DSpace. This would eliminate a
great deal of transitive dependency processing requirements and limit changes
to only be additions to the lib and/or WEB-INF/lib directories.
Likewise, I recommend not approaching webapplication overlaying and/or
alteration of existing configuration files in this process. But, if overlaying
were to be provided, it should be limited to only additions.
----
An approach to doing this might be possible using maven, assemblies and the
assembly process to write a deployment to a target ${dspace.dir}/lib,
${dspace.dir/webapps/xmlui/WEB-INF/lib and so on. The current release process
utilizes these (albiet we are working to shift to move the release assemblies
back into the source tree).
http://scm.dspace.org/svn/repo/tools/maven/dspace-assembly-plugin/trunk/src/main/resources/assemblies/
> 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.
--
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/dspace-devel
