DSpace now required Java 5 or greater because of usage of new language capabilities introduced in 5 that make coding easier and cleaner.

Java 5 or later can be downloaded from the following location: http://java.sun.com/javase/downloads/index.jsp

Maven is necessary in the first stage of the build process to assemble the installation package for your DSpace instance. It gives you the flexibility to customize DSpace using the exisitng Maven projects found in the [dspace-source]/dspace/modules directory or by adding in your own Maven project to build the installation package for DSpace, and apply any custom interface "overlay" changes.

Maven can be downloaded from the the following location: http://maven.apache.org/download.html

Apache Ant is still required for the second stage of the build process. It is used once the installation package has been constructed in [dspace-source]/dspace/target/dspace-<version>-build.dir and still uses some of the familiar ant build targets found in the 1.4.x build process.

Ant can be downloaded from the following location: http://ant.apache.org

With the advent of a new Apache Maven 2 based build architecture in DSpace 1.5.x, you now have two options in how you may wish to install and manage your local installation of DSpace. If you've used DSpace 1.4.x, please recognize that the initial build proceedure has changed to allow for more customization. You will find the later 'Ant based' stages of the installation proceedure familiar. Maven is used to resolve the dependencies of DSpace online from the 'Maven Central Repository' server.

Its important to note that the strategies are identical in terms of the list of proceedures required to complete the build process, the only difference being that the Source Release includes "more modules" that will be built given their presence in the distribution package.

Both approaches provide you with the same control over how DSpace builds itself (especially in terms of adding completely custom/3rd-party DSpace "modules" you wish to use). Both methods allow you the ability to create more complex user interface "overlays" in Maven. An interface "overlay" allows you to only manage your local custom code (in your local CVS or SVN), and automatically download the rest of the interface code from the maven central repository whenever you build DSpace. This reduces the amount of out-of-the-box DSpace interface code maintained in your local CVS / SVN.

Before beginning an installation, it is important to get a general understanding of the DSpace directories and the names by which they are generally referred. (Please attempt to use these below directory names when asking for help on the DSpace Mailing Lists, as it will help everyone better understand what directory you may be referring to.)

DSpace uses three separate directory trees. Although you don't need to know all the details of them in order to install DSpace, you do need to know they exist and also know how they're referred to in this document:

For details on the contents of these separate directory trees, refer to directories.html. Note that the [dspace-source] and [dspace] directories are always separate!

This method gets you up and running with DSpace quickly and easily. It is identical in both the Default Release and Source Release distributions.

In order to set up some communities and collections, you'll need to login as your DSpace Administrator (which you created with create-administrator above) and access the administration UI in either the JSP or XML user interface.

A couple of DSpace features require that a script is run regularly -- the e-mail subscription feature that alerts users of new items being deposited, and the new 'media filter' tool, that generates thumbnails of images and extracts the full-text of documents for indexing.

To set these up, you just need to run the following command as the dspace UNIX user:

crontab -e

Then add the following lines:

# Send out subscription e-mails at 01:00 every day
0 1 * * *  [dspace]/bin/sub-daily
# Run the media filter at 02:00 every day
0 2 * * *  [dspace]/bin/filter-media
# Run the checksum checker at 03:00
0 3 * * *  [dspace]/bin/checker -lp
# Mail the results to the sysadmin at 04:00
0 4 * * *  [dspace]/bin/dsrun org.dspace.checker.DailyReportEmailer
	-c

Naturally you should change the frequencies to suit your environment.

PostgreSQL also benefits from regular 'vacuuming', which optimizes the indices and clears out any deleted data. Become the postgres UNIX user, run crontab -e and add (for example):

# Clean up the database nightly at 4.20am
20 4 * * * vacuumdb --analyze dspace > /dev/null 2>&1

In order that statistical reports are generated regularly and thus kept up to date you should set up the following cron jobs:

# Run stat analyses
0 1 * * * [dspace]/bin/stat-general
0 1 * * * [dspace]/bin/stat-monthly
0 2 * * * [dspace]/bin/stat-report-general
0 2 * * * [dspace]/bin/stat-report-monthly

Obviously, you should choose execution times which are most useful to you, and you should ensure that the -report- scripts run a short while after the analysis scripts to give them time to complete (a run of around 8 months worth of logs can take around 25 seconds to complete); the resulting reports will let you know how long analysis took and you can adjust your cron times accordingly.

For information on customising the output of this see configuring system statistical reports.

In order to deploy a multilingual version of DSpace you have to configure two parameters in [dspace-source]/config/dspace.cfg:

default.locale, e. g. default.locale = en

webui.supported locales, e. g. webui.supported.locales = en, de

The Locales might have the form country, country_language, country_language_variant.

Accoding to the languages you wish to support, you have to make sure, that all the i18n related files are available see the Multilingual User Interface Configuring MultiLingual Support section for the JSPUI or the Multilingual Support for XMLUI in the configuration documentation.

If your DSpace is configured to have users login with a username and password (as opposed to, say, client Web certificates), then you should consider using HTTPS. Whenever a user logs in with the Web form (e.g. dspace.myuni.edu/dspace/password-login) their DSpace password is exposed in plain text on the network. This is a very serious security risk since network traffic monitoring is very common, especially at universities. If the risk seems minor, then consider that your DSpace administrators also login this way and they have ultimate control over the archive.

The solution is to use HTTPS (HTTP over SSL, i.e. Secure Socket Layer, an encrypted transport), which protects your passwords against being captured. You can configure DSpace to require SSL on all "authenticated" transactions so it only accepts passwords on SSL connections.

The following sections show how to set up the most commonly-used Java Servlet containers to support HTTP over SSL.

        ##  SSLVerifyClient can be "optional" or
	"require"
        SSLVerifyClient optional
        SSLVerifyDepth  10
        SSLCACertificateFile  
	path-to-your-client-CA-certificate
        SSLOptions StdEnvVars ExportCertData
   

First a few facts to clear up some common misconceptions:

If you want to use the Handle system, you'll need to set up a Handle server. This is included with DSpace. Note that this is not required in order to evaluate DSpace; you only need one if you are running a production service. You'll need to obtain a Handle prefix from the central CNRI Handle site.

A Handle server runs as a separate process that receives TCP requests from other Handle servers, and issues resolution requests to a global server or servers if a Handle entered locally does not correspond to some local content. The Handle protocol is based on TCP, so it will need to be installed on a server that can broadcast and receive TCP on port 2641.

The Handle server code is included with the DSpace code in [dspace-source]/lib/handle.jar. Note: The latest version of the handle.jar file is not included in the release due to licensing conditions changing between the provided version and later versions. It is recommended you read the new license conditions and decide whether you wish to update your installation's handle.jar. If you decide to update, you should replace the existing handle.jar in [dspace-source]/lib with the new version and rebuild your war files.

A script exists to create a simple Handle configuration - simply run [dspace]/bin/make-handle-config after you've set the appropriate parameters in dspace.cfg. You can also create a Handle configuration directly by following the installation instructions on handle.net, but with these changes:

Whichever approach you take, start the Handle server with [dspace]/bin/start-handle-server, as the DSpace user. Once the configuration file has been generated, you will need to go to http://hdl.handle.net/4263537/5014 to upload the generated sitebndl.zip file. The upload page will ask you for your contact information. An administrator will then create the naming authority/prefix on the root service (known as the Global Handle Registry), and notify you when this has been completed. You will not be able to continue the handle server installation until you receive further information concerning your naming authority.

Note that since the DSpace code manages individual Handles, administrative operations such as Handle creation and modification aren't supported by DSpace's Handle server.

If you need to update the handle prefix on items created before the CNRI registration process you can run the [dspace]/bin/update-handle-prefix script. You may need to do this if you loaded items prior to CNRI registration (e.g. setting up a demonstration system prior to migrating it to production). The script takes the current and new prefix as parameters. For example:

[dspace]/bin/update-handle-prefix 123456789 1303

will change any handles currently assigned prefix 123456789 to prefix 1303, so for example handle 123456789/23 will be updated to 1303/23 in the database.

To aid web crawlers index the content within your repository, you can make use of sitemaps. There are currently two forms of sitemaps included in DSpace; Google sitemaps and HTML sitemaps.

Sitemaps allow DSpace to expose it's content without the crawlers having to index every page. HTML sitemaps provide a list of all items, collections and communities in HTML format, whilst Google sitemaps provide the same information in gzipped XML format.

To generate the sitemaps, you need to run [dspace]/bin/generate-sitemaps This creates the sitemaps in [dspace]/sitemaps/

The sitemaps can be accessed from the following URLs:

HTML sitemaps follow the same procedure:

When running [dspace]/bin/generate-sitemaps the script informs Google that the sitemaps have been updated. For this update to register correctly, you must first register your Google sitemap index page (/dspace/sitemap) with Google at http://www.google.com/webmasters/sitemaps/. If your DSpace server requires the use of a HTTP proxy to connect to the Internet, ensure that you have set http.proxy.host and http.proxy.port in [dspace]/config/dspace.cfg

The URL for pinging Google, and in future, other search engines, is configured in [dspace-space]/config/dspace.cfg using the sitemap.engineurls setting where you can provide a comma-separated list of URLs to 'ping'.

You can generate the sitemaps automatically every day using an additional cron job:

# Generate sitemaps


0 6 * * * [dspace]/bin/generate-sitemaps
       

You'll need to install this pre-requisite software: