Book Image

Apache Maven 2 Effective Implementation

By : Brett Porter, Maria Odea Ching
Book Image

Apache Maven 2 Effective Implementation

By: Brett Porter, Maria Odea Ching

Overview of this book

<p>By building up a sample application, this book guides developers painlessly through building a project with Maven. This book shows you how to combine Maven with Continuum and Archiva, which will allow you to build an efficient, secure application and make developing in a team easy.<br /><br />You may already be aware of the pitfalls of 'integration hell' caused by changed code being submitted to repositories by a number of developers. When you implement Continuum in your build, you can easily perform continuous integration, avoiding timely rework and reducing cost and valuable time. You will be able to use Maven more efficiently in a team after you learn how to set up Archiva, Apache's repository manager.<br /><br />It's easy to quickly get to work with Maven and get the most out of its related tools when you follow the sequential coverage of the sample application in this book. A focus on team environments ensures that you will avoid the pitfalls that are all too common when working in a team. Soon, by learning the best practices of working with Maven, you will have built an effective, secure Java application.</p>
Table of Contents (21 chapters)
Apache Maven 2 Effective Implementation
Credits
About the Authors
About the Reviewers
Preface
Free Chapter
1
Maven in a Nutshell
Index

Database backup and migrating between versions


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.

Migrating Continuum

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:

http://repo1.maven.org/maven2/org/apache/continuum/data-management-cli/1.2.3.1/data-management-cli-1.2.3.1-app.jar

http://repo1.maven.org/maven2/org/apache/continuum/data-management-cli/1.3.3/data-management-cli-1.3.3-app.jar

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.

Migrating Archiva

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