In the notes below
In DSpace 1.8.0, there have been a few significant changes to how you upgrade and configure DSpace. Notably:
Before you start your upgrade, it is strongly recommended that you create a backup of your DSpace instance. Backups are easy to recover from; a botched install/upgrade is very difficult if not impossible to recover from. The DSpace specific things to backup are: configs, source code modifications, database, and assetstore. On your server that runs DSpace, you might additionally consider checking on your cron/scheduled tasks, servlet container, and database.
Make a complete backup of your system, including:
pg_dump -U [database-user] -f [backup-file-location] [database-name]
[dspace]/assetstoreby default, and any other assetstores configured in the
[dspace]/config/dspace.cfg"assetstore.dir" and "assetstore.dir.#" settings)
cd [dspace-source]/dspace/ mvn -U clean package
[dspace-source]/dspace/target/dspace-[version]-build.dir. Inside this directory is the compiled binary distribution of DSpace. Before rebuilding DSpace ('package'), the above command will clean out any previously compiled code ('clean') and ensure that your local DSpace JAR files are updated from the remote maven repository.
$CATALINA_HOME/shutdown.shscript. (Many Unix-based installations will have a startup/shutdown script in the
cd [dspace-source]/dspace/target/dspace-[version]-build.dir ant -Dconfig=[dspace]/config/dspace.cfg update
Applying a database change will alter your database! The database upgrade scripts have been tested, however, there is always a chance something could go wrong. So, do yourself a favor and create a backup of your database before you run a script that will alter your database.
*.oldfiles in your newly updated
[dspace]/config/directory (and all sub-directories). During the update process, if there is a difference between your old 1.7-compatible configuration file and the new 1.8-compatible configuration file, your previous settings will be moved to a
*.oldfile. You may want to review the differences between the
*.oldfile and the new version of that file, and ensure your previous configurations/settings are merged into the new configuration file. One way to compare these files is by using a comparison-utility like
diffor a text editor that supports file comparison.
dspace.cfgwhich now support richer features, such as iTunes podcast and publishing to iTunesU
dspace.cfgand separated into their own config files. Configuration sections which have been moved include Authentication settings, Batch Metadata Editing settings, Discovery settings, OAI-PMH/OAI-ORE settings, Statistics settings and SWORD settings. So, any configurations from these sections should be removed from your existing dspace.cfg file, as they will be ignored. For more information, see the Changes to the DSpace 1.8 Upgrade / Configuration Process note at the top of this page.
[dspace]/config/modules/directory. Each of these corresponds to a new feature in 1.8.0 (or a configuration section which has now been moved out of the dspace.cfg file):
authentication-*.cfgfiles : new location for Authentication Configurations.
bulkedit.cfg: new location for Batch Metadata Editing Configurations.
discovery.cfg: new location for Discovery Configurations.
fetchccdata.cfg: configuration for new "Fetch CC Data" Curation Task.
oai.cfg: new location for OAI-PMH / OAI-ORE Configurations.
solr-statistics.cfg: new location for Solr Statistics Configurations.
spring.cfg: configuration file for DSpace Service Manager (should not need modification).
submission-curation.cfg- configuration file for new Virus Scanning on Submission feature.
sword-client.cfg: configuration file for new SWORDv1 Client feature.
sword-server.cfg: new location for SWORDv1 Server Configurations.
swordv2-server.cfg: configuration file for new SWORDv2 Server feature.
translator.cfg: configuration for new "Microsoft Translator" Curation Task.
workflow.cfg: configuration for new Configurable Workflow feature.
[dspace]/config/spring/directory which holds Spring Framework configuration files. The vast majority of users should never need to modify these settings, but they are available for hardcore developers who wish to add new features via the DSpace Services Framework (based on Spring Framework).
[dspace]/webappsdirectory to the subdirectory of your servlet container (e.g. tomcat):
cp -R [dspace]/webapps/* [tomcat]/webapps/
In DSpace 1.6.x & 1.7.x the file download statistics were generated without regard to the bundle in which the file was located. In DSpace 1.8.0 it is possible to configure the bundles for which the file statistics are to be shown by using the query.filter.bundles property. If required the old file statistics can also be upgraded to include the bundle name so that the old file statistics are fixed.
Updating the file statistics will ensure that old file downloads statistics data will also be filterable using the filter bundle feature. The benefit of upgrading is that only files within, for example, the "ORIGINAL" bundle are shown as opposed to also showing statistics from the LICENSE bundle. More information about this feature can be found at Statistics differences between DSpace 1.7.x and 1.8.0
Applying this change will involve dumping all the old file statistics into a file and re-loading them. Therefore it is wise to create a backup of the [DSpace]/solr/statistics/data directory. It is best to create this backup when the Tomcat/Jetty/Resin server program isn't running.
When a backup has been made, start the Tomcat/Jetty/Resin server program.
The update script has one option (
-r) which will, if given, not only update the broken file statistics but also delete statistics for files that were removed from the system. If this option isn't active, these statistics will receive the "BITSTREAM_DELETED" bundle name.
#The -r is optional [dspace]/bin/dspace stats-util -b -r