AddOnMechanism > Add``On Mechanism Prototype

AddOn Mechanism Prototype

There is an initial prototype of an Add``On Mechanism proposed for DSpace currently available in CVS. This can be obtained from the Tapir Source``Forge page:

http://sourceforge.net/projects/tapir-eul

There are two modules that are important:

• Add``On - This module contains a skeleton add-on that supported DSpace add-ons should be implemented with. It consists of a standardised build file which needs to be filled out to meet the needs of the add-on, and a directory structure to which add-ons should conform. Each directory contains a README file with scope notes to aid population. In addition, there is a dspace directory which contains proposed additions and changes to the current DSpace core to support the add-on process. Currently this consists only of a new build file which is capable of delegating to the add-on's own build file in a structured way, and a class to import required DC metadata fields to the DC type registry. Further additions planned include changes to the way that CSS files are managed and the addition of a org.dspace.addon package which will contain the tools that the new build file will implement to aid installation of add-ons, such as building config files and so forth.

• Tapir-1 - This module contains the new version of Tapir which will eventually be released as v1.0. This add-on is being developed alongside the Add``On Mechanism as an example of implementation and a driver for functionality. At time of writing the core java, the JSPs, the database tables and the required DC fields can be installed using the build mechanism in the Add``On module. Current challenges are to smooth over the process of configuration, which will no doubt form the hardest part of the Add``On Mechanism. No claim is made at this stage that the Tapir will actually function correctly once installed.

Access to these modules can be obtained via anonymous CVS access using the CVSROOT:

/cvsroot/tapir-eul

. Write access to the repository will be made available to current DSpace committers if desired. Patches and suggestions are welcome and encouraged. If you have an add-on that you would like to produce as an experiment with this mechanism please do so, and use the dspace-devel mailing list to collaborate with others.

Note: This Add``On Mechanism supports only the installation of one add-on at a time using a syntax like:

 % ant -Dinstall=/path/to/addon addon

Updates on the work available at the bottom of this page...

Java Source

This Add``On Mechanism does not support patching the DSpace source code. The intention is that all new add-ons will provide (if necessary) their own java source and build it into their own jar file. The skeleton add-on build file contains examples of how to do this. This jar file will then be included by the DSpace build file into the standard library.

The reason for this decision is that patching the source is not technically adding on, but rather adding in, which will produce maintenance problems in the long term which may be difficult to resolve. We are therefore encouraging add-on writers to make their code stand as separately as possible from the DSpace core (although obviously it can be built against the dspace library).

JSP Files

Currently the Add``On Mechanism does not attempt to merge add-on JSPs with existing DSpace JSPs, and may well never do so. Instead all JSPs are simply copied into the

[dspace]/jsp/local

directory for deployment along with all other localisations. This means that there may be clashes with existing localisations, or other add-ons, and there is currently no mechanism to deal with this. Suggestions welcome for the best way to deal with this. The initial idea was to produce an Add``On Mechanism to aid the installation of third party tools, but not necessarily to guarantee success. Perhaps at this stage a simple warning process would be warranted.

Database tables

Aside from Rob's suggestions regarding good practice in making schema changes (i.e. do not modify core D

Update 11/11/2005

I have had a go at the build time configuration process, and have come up with the following procedure:

If fresh_install is requested:

1. Move all source configs from

   [dspace-source]/config

   to

   [dspace-source]/build/config

2. Copy the file referenced by

    $\{config\} 

   into

    [dspace-source]/build/config 

   in case it is not the default

3. init_configs

   target moves the contents of

   [dspace-source]/build/config

   to

   [dspace]/config

4. ConfigurationManager -installTemplate

   still operates on

   [dspace]/config

If

addon

is requested:

1. AddOnConfigurator is called which opens

   [addon-source]/config/dspace.cfg

   and appends it to

   [dspace-source]/build/config/dspace.cfg

   along with a note to edit the source config, not the live config
2. The target update is called. This will need to move all new config files into the live directory, which may require

   ConfigurationManager -installTemplate

   to be run again

Other thoughts:

• some add-ons will come with additional configuration files. These will need to be moved into

  [dspace-source]/build/config

  and then copied over during update

• the whole process will eventually rely on all the sources being available. Perhaps the very first thing to do would be to copy the add-on source into the dspace source tree somewhere, and build from that version. At least then folk will only have to be sure to keep the one top level directory intact. Or perhaps they could all be stored in

  [dspace]/addon

  as full sources (perhaps the dspace source tree needs to be maintained this way too?)

Unfortunately the code to do the above processes is stuck on my computer until I can get in contact with the CVS server again. Sometimes getting onto SF during the afternoon in Northern Europe is pretty difficult. I will upload it at the start of next week. In the mean time attached is a tarball with the current state of the Add``On package at my end: ^addon-2005-11-11.tar.gz