Page History
...
Wiki Markup |
---|
For the example, assume these files reside under a _development_ directory, _{{\{development\}}}_. To add these classes to the LNI module, we install the sources under {{_\[source\]_/dspace/modules/lni/src/main/java}} with the following commands: |
Code Block |
---|
mkdir -p _[source]_/dspace/modules/lni/src/main/java/edu/mit/libraries/facade cp _\{development\}_/edu/mit/libraries/facade/*.java _[source]_/dspace/modules/lni/src/main/java/edu/mit/libraries/facade |
...
Code Block |
---|
# Crosswalk Plugins: plugin.named.org.dspace.content.crosswalk.IngestionCrosswalk = \ *edu.mit.libraries.facade.PIMCrosswalk = PIM \* org.dspace.content.crosswalk.PREMISCrosswalk = PREMIS \ ... |
...
Wiki Markup |
---|
If your code has any new external dependencies (i.e. it needs modules not already required by DSpace) then you need to add those to the POM for the overlay module. In this example, we add the *bold*dependency lines to the LNI module's POM at {{_\[source\]_/dspace/modules/lni/pom.xml}} |
Code Block |
---|
<project>
|
Panel |
... ...
<dependencies>
...
<dependency>
<groupId>org.openrdf</groupId>
<artifactId>sesame</artifactId>
<version>2.1</version>
</dependency>
</dependencies>
</project>
|
NOTE: Of course, this requires that all the libraries your code depends on are available to Maven. If NOTE: Of course, this requires that all the libraries your code depends on
are available to Maven. If not, you'll have to add them to the local
Maven repository or convince someone to put them into a networked maven
repository. This example creates an entry in the local repository:
Panelcode |
---|
mvninstall:install-file \ -Dfile=/opt/sesame/lib/openrdf-sesame-2.1-onejar.jar \ -DgroupId=org.openrdf \ -DartifactId=sesame \ -Dversion=2.1 \ -Dpackaging=jar \ -DgeneratePom=true install:install-file \
-Dfile=/opt/sesame/lib/openrdf-sesame-2.1-onejar.jar \
-DgroupId=org.openrdf \
-DartifactId=sesame \
-Dversion=2.1 \
-Dpackaging=jar \
-DgeneratePom=true
|
Step 4: Build with Maven and Deploy
First, build the sources:
Panelcode |
---|
cd [source]/dspace mvn package |
Assuming that succeeds, run Ant to install the build products.
NOTE: This does NOT install the configuration files, because I don't work that way; perhaps someone who does could add an alternate command here?
Panelcode |
---|
\{ shut down servlet container such as Tomcat \} cd [source]/dspace/target/dspace-1.5.0-build.dir ant update \{ start up servlet container such as Tomcat \} |
Your DSpace instance should now be running with the new plugins in the
LNI application.
Adding The Same Plugins to Other Applications
The procedure to add these same plugins to another DSpace application,
for example the OAI-PMH server ("oai"
), is identical.
If you are adding
the plugins to both lni
and oai
, you may
wish to symbolically link the Java sources to one master copy someplace
else, so that any changes will take effect in both applications.
In the case of OAI-PMH, you'll also need to modify the
oaicat.properties
configuration file to add the appropriate
plugins to OAICAT.
Recipe 4: (Deprecated) Use Overlays to Segregate Local Modifications
You can also use the overlay mechanism to implement a local change or bug-fix
to the DSpace codebase. The process is exactly the same as for
adding plugin implementations, only you add the appropriate DSpace
class files to the source directory instead. These will take precedence
over the distributed code in the classloader.
Wiki Markup |
---|
Again, add the sources |
source
under {{_\[source\]_/dspace/modules/_\{MODULE\}_/src/main/java}} , |
only under the {{org/dspace/...}} hierarchy. |
For example, to fix a bug in the org.dspace.app.oai.DSpaceOAICatalog
class, you add that file in Step 1 instead of your own source:
Panelcode |
---|
mkdir -p p [source]/dspace/modules/oai/src/main/java/org/dspace/app/oai cp \{development\}/org/dspace/app/oai/DSpaceOAICatalog.java [source]/dspace/modules/oai/src/main/java/org/dspace/app/oai |
The procedure thereafter is exactly the same as the last recipe (deprecated) for adding plugin
implementations.
Recipe 5: (Deprecated) Old, Poor way of Adding Plugins to Command-Line Applications
The build system does not appear to have any way to accomplish this
with a binary DSpace installation.
(Please correct this if I'm wrong.)
As a kludgy workaround, I've simply added a JAR file manually to the
"lib" directory used by all command-line apps.
Using my crosswalk and packager example above, the command to add my
code to the runtime directory is:
Panelcode |
---|
cd [source]/dspace jar cvf [dspace]/lib/pim.jar \ -C target/dspace-1.5.0-build.dir/webapps/oai/WEB-INF/classes/ edu |
Note that the JAR output file pim.jar
is simply what I chose to call it, use any unique name.
The classes are all in packages under edu.mit
so the
jar command picks up everything under edu
in the overlay module's
class directory.
Of course you also have to manually copy in whatever other
libraries your code depends on, e.g.
Panelcode |
---|
cp /opt/sesame/lib/*.jar _[dspace]_/lib |
Note that the build installation ("ant update") process wipes the
runtime "lib"
directory clean each time, so you'll have to
repeat these commands after every new update.