Skip to end of metadata
Go to start of metadata

Web-based, open-source collections management software for museums and more ...

CollectionSpace is a web-based, open source collections management and information system for museums and other collecting institutions. You can use it to manage your museum's cataloging, acquisitions, loans, and many other activities.


If you're evaluating or implementing a CollectionSpace system, you can find readily navigable links to the currently available documentation in the left sidebar, as well as top-level links below.

Tip: The left sidebar makes finding documentation easier


To view the Table of Contents links in the left sidebar, click this icon in the upper-right area of this page:



Release Notes for v4.2


Areas of work for CollectionSpace Release 4.2 include:

  • Upgrade the Nuxeo EP framework, the enterprise content management framework that serves as one of CollectionSpace's major underpinnings, to its latest version, 6.0.x. Related upgrades and improvements also include:
    • Upgrade the Tomcat JEE container to version 7.0.x.
    • Upgrade many Maven build plugins, tools, and POM files, resulting in dramatically faster build times. This in turn makes it faster to install CollectionSpace, as well as faster to develop, test, and deploy certain code and configuration changes.
    • Ability to ship with OpenJDK (instead of the Oracle JDK), simplifying the installation process and making that process more reliable.
  • Addition of a community-contributed Exhibition Planning procedure, to manage the planning and management of exhibitions. This procedure encompasses tracking the objects included in or considered for an exhibition, the people involved in the exhibition's activities, and the exhibition sections, if any. (For a list of fields included in this procedure, see Exhibition Management Schema.)
  • Addition of the Fine and Contemporary Art profile, which incorporates the Fine Art Extension Set and Variable Media Extension Set. This is CollectionSpace's first community-defined profile, with more to come in future releases. As a quick overview of profiles and their constituent parts:
    • A selected group of procedures, term authorities, and extensions, which support the work of a specific community of practice, such as fine art or anthropology, are referred to as that community's profile. (Often, procedures and authorities within the profile may be further configured, or even slightly changed, to better support the needs of that community of practice.)
    • An extension is a group of fields added to a single procedure or authority to support the work of a specific community of practice. Extensions added to more than one procedure or authority are referred to collectively as extension sets.
    • Documentation for implementing Extensions and Profiles is available.
  • Fixes to any remaining critical stability bugs selected from a small list of spotlighted issues. (Most of these issues were addressed in the previous Release 4.1.)
  • Other bugfixes as prioritized by the CollectionSpace community. The full list of issues to be prioritized may be found by following this link.

For a detailed list of changes made in this release - feature enhancements, bugfixes and more - please see the Resolved Issues and Tasks for version 4.2 in the project's issue tracker.


Changes you'll need to make when upgrading to version 4.2

Upgrading to Tomcat 7

You'll need to upgrade the existing CollectionSpace Tomcat 6 to the new CollectionSpace Tomcat 7:

First, you'll set up the new Tomcat folder (sample instructions given here for Ubuntu 14.04):

Go to the directory where you want to install CollectionSpace:

CollectionSpace runs in the Tomcat 7 application server and a pre-configured version of Tomcat 7 is provided.

Start by downloading the tomcat tarball:

Unpack the the tarball:

This will create an apache-tomcat-7.0.57 directory in /usr/local/share.

Next, make necessary files executable:

You can now remove the tarball:

Then you will need to update any existing environment variables to reflect the path to the Tomcat 7 folder. Most likely, this will only be:


but, depending on how you set your variables, may also include: 


Migrating Binaries

CollectionSpace (via Nuxeo) stores binaries, like images uploaded as part of Media Handling records, in a directory in tomcat. This directory will need to be manually copied over from Tomcat 6 to tomcat 7.

So, to copy over all the data from the core tenant you can run:

Binaries from other tenants will be in a /usr/local/share/apache-tomcat-6.0.3/nuxeo-server/data/TENANT_NAME/. For the Life Sciences tenant, for example, the TENANT_NAME directory is  lifesci_domain, as defined in the lifesci tenant settings file in the application layer.

If Tomcat7 is running when the binary directories are migrated, it will need to be stopped and restarted.

Adding new Environment Variables

You'll need to add three new, required environment variables:

New environment variable (CollectionSpace 4.2 and higher)Replaces earlier environment variablePurpose / notes


(no previous equivalent)

A string identifying a specific instance of a CollectionSpace server. It should begin with an underscore. The recommended value is simply _default  However, if your server will be part of a configuration where two or more CollectionSpace servers will be storing their data in the same PostgreSQL database server, set this instead to a unique name for your server; e.g., _myservername  (This string will be appended to the names of certain databases and database users, to help avoid naming conflicts.)

DB_HOST(no previous equivalent)The hostname or IP address for the machine/server running the PostgreSQL database server. E.g., localhost,, etc.
DB_PORT(no previous equivalent)The port number that the PostgreSQL database server is listening on. This is usually 5432.
 JEE_PORT (no previous equivalent)The port number for the CollectionSpace services layer.  This is usually 8180.

Required Database changes

If you plan to continue to use your existing cspace database after upgrading to v4.2 - and you will want to do that under nearly all circumstances - you'll need to - just once - make a few changes to the database to make it compatible with 4.2.  To do so, connect to your PostgreSQL database server using either a graphical client or the command line psql client; log in via an account with administrative privileges, such as CollectionSpace's csadmin account or the default postgres account (if the latter is present).

(Note: if you've instance-qualified your CollectionSpace server, the name of the cspace database might include an instance ID suffix and thus its name may look something like cspace_myinstancename. If so, be sure to substitute that name for each instance of cspace in the instructions below.)

Changing a database table column name

Starting with version 4.2, due to an upgrade of one of its components, CollectionSpace expects that, in the accounts_tenants table of the cspace database, the column formerly named TENANTS_ACCOUNTSCOMMON_CSID will have been changed to a new name, TENANTS_ACCOUNTS_COMMON_CSID (i.e. with an underscore added between ACCOUNTS and COMMON.) As a result, you'll need to rename that column in your database to reflect this changed expectation.

Assuming you have already connected via psql or a graphical client, connect to the cspace database:

Rename this column in the appropriate database table:

Instance qualify existing databases and roles

You'll need to instance qualify several database and role names so they work with the instance qualification that was introduced in 4.2.

First weill instance qualify the tenant and nuxeo databases by appending the value of $CSPACE_INSTANCE_ID to the database name. If using the recommend default value for $CSPACE_INSATNCE_ID id "_default", the core tenant database name will become cspace_default. To rename the database, you can run:

Next, the same instance qualifying operation needs to be taken for the roles which operate on those databases.

When the postgresql role name is altered, the password for that role is reset, so for each role we need to reset the password to the value set in environment variables.

Finally, client authentication needs to be instance qualified as well, which is done by updating the pg_hba.conf configuration file, which is located (for Ubuntu) on at /etc/postgresql/9.3/main/pg_hba.conf.

Under the section starting with # Rule Name: cspace user via IPv4 add a line for the instance qualified database.

and under the section starting with # Rule Name: nuxeo user via IPv4 add

which should then look like:

Postgresql will need to be restarted after that change is made.

Ant Import Task

Finally, because 4.2 introduces a new tenant, the Fine and Contemporary Art profile tenant, the ant import task needs to be run in the services layer code to ensure that admin users are created for that tenant.

To do that, navigate to the directory where you have checked out the services layer code, something like as /home/cspace/cspace_source/services and then run:


System Requirements

In System Requirements, you can find the system requirements for running a CollectionSpace system, as well as a list of supported web browsers for accessing your system.

Using CollectionSpace

If you are new to CollectionSpace, you can get a good sense of how it works from the demo available on the CollectionSpace website.

The User Manual describes how to use CollectionSpace 4.1's features to manage your collections. This manual also provides a useful overview of CollectionSpace's basic feature set.

Installing CollectionSpace

CollectionSpace is installed on a server and accessed using a web browser. No software needs to be installed on your users' computers.

You can find general server installation instructions that apply to all supported environments in Installing CollectionSpace, as well as detailed instructions for several specific platforms.

Configuring CollectionSpace

If you are an implementer or consultant, you can adapt CollectionSpace for the specific needs of your museum or client via the documentation in Configuring CollectionSpace.

The documentation in Configuring CollectionSpace focuses on configuration: changing the behavior and the look and feel of the system by making changes via web-based Administration pages and by editing text files: HTML templates, CSS stylesheets, XML- and JSON-based configuration files, and properties files.

To learn about customization - extending the system's functionality by working with the system's Java and JavaScript source code or adding code of your own - please see Developing for CollectionSpace.

Maintaining CollectionSpace

Once you have your deployment up and running, you'll want to take care of it. In Maintaining CollectionSpace, you'll find both operational suggestions and troubleshooting techniques.

Upgrading CollectionSpace

If you have an older version of CollectionSpace and want to upgrade it to a newer version, Upgrading CollectionSpace provides pertinent tips.

Migrating to CollectionSpace

When you want to migrate your existing data into a CollectionSpace system, Migrating to CollectionSpace can help you do this.

Developing for CollectionSpace

If you are building or integrating applications or scripts that talk to CollectionSpace systems, or are a CollectionSpace software developer, integrator, or implementer who wishes to extend the system's capabilities by working with its source code, you can find documentation on these topics in Developing for CollectionSpace. This topic area includes details about CollectionSpace's Application Programming Interfaces (APIs).

Hosting CollectionSpace

If you're hosting multiple CollectionSpace systems, whether in-house or as a service provider, Hosting CollectionSpace can help you find resources relevant to this task.

Reference Information

Reference Information provides supporting information and requirements for CollectionSpace, and includes general documents that are referenced from across two or more of the topic areas above.

Documentation Feedback

Many documentation additions and updates are planned. Please feel free to comment on the CollectionSpace project's Talk Mailing List if you have suggestions for improving current documentation, or if there is documentation you would like to see in the future.

  • No labels

1 Comment

  1. In the Configuring CollectionSpace section, a reviewer added this note:

    Need to elaborate on difference between developer and implementer documentation. Need to clarify not just what we mean by dev vs. implementer, but also when someone might want to use one set of documentation over the other (because they're not exclusive distinctions).