One pain point for me w.r.t. DSpace is that plugins are baked in at build time. It's quite possible, and arguably desirable, to write plugins in such a way that they are not strongly dependent on the DSpace version, and could just be dropped in and configured on. The problem is that the next 'ant update' will push aside the lib and webapps directories and provide new ones, so one's dropped-in plugin is now missing.
What do you think of adding a "site plugins" directory (say, [DSpace]/plugins) in which the plugin manager will look for plugins that are *not* part of stock DSpace? It can probably be done by providing a ClassLoader that is configured (in dspace.cfg) to look there, and having PluginManager use it to load configured plugins. (A normal classloader will first delegate to its parent, so plugins will be found in the usual places if they are there and only be sought in the "site plugins" directory if not.) Fair warning: there are likely other component types that should be able to live where they will not be blitzed by a DSpace update. -- Mark H. Wood Lead Technology Analyst University Library Indiana University - Purdue University Indianapolis 755 W. Michigan Street Indianapolis, IN 46202 317-274-0749 www.ulib.iupui.edu
signature.asc
Description: Digital signature
------------------------------------------------------------------------------
_______________________________________________ Dspace-devel mailing list Dspace-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-devel
