As new features, additional fixes and new releases come, the need to upgrade an application to a more recent version becomes imminent. This holds true for both Archiva and Continuum. Looking at the history of these two projects, they both have come a long way already. A lot has changed since their very first releases.
One of the usual problems when upgrading an application is data migration. Since both applications have their own databases, they also face the same problem when upgrading.
Project information, build configuration, build results, release results—these are just a few of the things that Continuum keeps track of in its database. Since we're dealing with history, we can't just wipe out the database and start anew.
It's a good thing that Continuum includes a database migration tool for each release. For our demonstration, we will assume that we are upgrading from 1.2.3 to 1.3.3 and we'll only be migrating just the Continuum database. The first thing that we need to do is get the database migration tool for the respective releases. Just a caution though, the 1.2.3 database migration tool has some problems so a 1.2.3.1 version of the tool was released to address this. We can get these tools at:
To perform the actual migration, you need to stop the running Continuum 1.2.3 instance first. Then to back up the old database, execute the following from the command line:
java -Xmx512m -jar [PATH/TO/1.2.3.1_DB_MIGRATION_TOOL]/data-management-cli-1.2.3.1-app.jar -buildsJdbcUrl jdbc:derby:[PATH/TO/1.2.3_DB]/data/databases/continuum -mode EXPORT -directory backups
Once the backup action has finished executing and the old database has been backed up, unpack the 1.3.3 binaries and start the instance. This is necessary in order to create the new database schema. Once it has successfully started, shut it down.
Now from the command line, execute the following:
java -Xmx512m -jar [PATH/TO/1.3.3_DB_MIGRATION_TOOL]/data-management-cli-1.3.1-app.jar -buildsJdbcUrl jdbc:derby:[PATH/TO/1.3.3_DB]/data/databases/continuum -mode IMPORT -directory [PATH/TO/1.2.3_BACKUP]/backups
Manually update the next sequence of the IDs of the tables in the database. Set the next sequence to the highest ID value incremented by one. After doing this, start up the 1.3.3 Continuum instance.
Tip
You can use Liquibase (http://www.liquibase.org/) to verify if the database schema is correct after migration.
If you want to retain your old Continuum configuration, just copy the continuum.xml
file (in conf/
) of the old Continuum instance to the new one.
It is fairly easy to upgrade Archiva compared to Continuum, since the repositories are in the local filesystem and the database and index can be easily re-created.
We will be upgrading Archiva from 1.1.4 to 1.2.1 for this demonstration. Assuming that we're not overly concerned with re-creating the Archiva database and we just want to retain the existing users, upgrading is as simple as follows.
Tip
Since the index format changed in Archiva 1.2 and 1.2.1, you need to re-create the index when upgrading from an older version of Archiva.
First, stop the running 1.1.4 instance then unpack the 1.2.1 binaries. Copy the users database from the 1.1.4 instance (found in data/databases/
if using the default configuration) to the data/databases/
directory of the unpacked 1.2.1 binaries. You also need to copy the Archiva configuration file so you won't have to configure everything again. Just overwrite the archiva.xml
file in the conf/
directory of the new installation with the one from the old Archiva instance.
Now, delete the index of each repository configured in the archiva.xml
file. The default location is in the [REPOSITORY_ROOT_DIRECTORY]/.index
, otherwise check the <indexDir>
of the repository set in the configuration file.
Start the 1.2.1 instance. Execute the repository scanning for each repository and then the database scanning afterwards. Both are optional though since these tasks are scheduled. Do this only if you want your index and database to be immediately populated.
In cases when you want to retain the Archiva database, you need to execute the command below for each repository. Archiva only processes artifacts for indexing and database updates if and only if the artifact has been modified after the last repository scan. As the database is already populated, Archiva will no longer process the artifacts in the repositories when the scanning executes and our index will not be created.
repositories$ find [REPOSITORY_DIRECTORY_NAME] | xargs touch