This page describes our current maven build infrastructure at JBoss.org and describes plans for the new repository configuration.

Existing Setup

There are currently two maven repositories as part of JBoss.org:Maven Release Repository and MavenSnapshotRepository.

Maven Release Repository

• The releases repository is a web based maven 2 repository located at http://repository.jboss.org/maven2.

• This repository is under version control (https://svn.jboss.org/repos/repository.jboss.org/maven2), and is periodically updated based on the changes in the version control system.

• md5 and sha1 files should be generated by maven and uploaded with the artifact during the release.

• (TODO) The files in this repository should be available through rsync so that the public maven repository can retrieve new releases.  This will allow the central maven repository to stay synchronized with jboss releases, and allow external projects to easily use the jboss artifacts as needed.  More information about how to do this can be found here: http://maven.apache.org/guides/mini/guide-ibiblio-upload.html.  The section about maven partners has more information.

MavenSnapshotRepository

• The snapshot repository contains only snapshot versions of artifacts.  This includes nightly builds and development builds.  Release versions such as beta, CR, GA, etc, should not be uploaded to this repository.

• These files do not need to be under version control (svn).  They should only be used until the next snapshot is generated, or the  version is released.

• The artifacts should be deleted after 30 days.

• The snapshot repository is located at the URL (http://snapshots.jboss.org/maven2).

• The repository should be available through the webdav protocol over https.  Each project with a maven build script will be able to deploy artifacts to the snapshot repository through this protocol.

• md5 and sha1 files should be generated by maven and uploaded with the artifact during the release.

Plan for Improved Repository Infrastructure

Goals

Searching for Artifacts.  Currently there is not an easy way to search the JBoss repository for artifacts without using external tools.  A repository manager such as Nexus will allow artifacts to be found more easily.

Tracking Thirdparty Aritfacts used in Builds.  It is a requirement that we keep a copy of all artifacts (jar files, etc) used in our builds.  Currently this is a tedious and time consuming manual process to copy thirdparty depenendencies and upload them to the jboss repository.  A repository manager can automatically save a copy of each downloaded artifact and keep a record of where it came from.

Staging Environment for Releases.  There is currently no staging environment where releases can be tested before they are deployed to the maven repository.  A repository manager could provide a staging environment to allow releases to be tested, and then the deployment would either be cancelled (if there are test failures) or the deployment would complete (if everything works correctly).

Repository Configurations. Configuration to combine the various maven repositories is currently handled by users/developers.  A maven repository manager would allow us to create more complex rules regarding how artifacts (dependencies) are retrieved.  The configuration for the users/developers should remain simple and require only minor modification to local maven settings (settings.xml).

Create a Legacy Repository for artifacts that should no longer be used but may be needed by some older builds.  This will help keep the main repository free of broken artifacts, and other files that should not be used.

Use Cases

Normal Development Cycle.  While working on JBoss projects developers will normally need access to several repositories: maven2_releases, maven2_snapshots, the central maven repository (repo1.maven.org), and possibly other external repositories such as the Sun repository (http://download.java.net/maven/2/).  A repository manager could host a single virtual repository that contains all of these repositories.  This would allow a simple developer configuration, and would also keep a copy of any artifacts downloaded from external repositories.

Development Build Deployment.  During the development cycle snapshot versions of artifacts often need to be deployed to the repository so they can be used by other projects.  Snapshot deployment should be a simple process just requiring a URL either directly to the snapshot repository, or deploying through a repository manager.

Release Builds.  When a project is released, it should be built using only the jboss release repository and possibly artifacts that have been copied from other repositories.  The snapshot and legacy repositories should not be included during these builds.

Release Build Deployment. Deploying a release should be a two step process.  The first step is to deploy the artifacts to a staging area managed by the repository manager.  This allows the artifacts to be reviewed and tested before the project is released.  The second step is to release the artifacts to the repository to be made permanently available.

Rebuilding old Releases.  Occasionally old releases need to be rebuilt from source.  These may require use of the legacy repository.  A virtual repository should be available for these builds which includes the legacy repository.

Deploying Thirdparty Jars.  This includes any jar that needs to be deployed to the Maven repository, but does not come from a jboss.org project.  This could include  jars which are not available in any Maven repository.  Or it could be a patched version of a jar available in the central repository.  The process for deploying these jars available should be simple and standardized for all developers.

Repository Manager

Requirements

MavenRepositoryManagerRequirements

Configuration

The repository manager (Nexus) allows virtual repositories (repository groups) to be created.  This allows for separate URLs for different repository configurations.  More specific information about the repository manager configuration can be found at the page Maven Repository Organization

Repository Deployment

The current repository setup uses svn to deploy to the releases repository.  This is not ideal because there is no shared staging environment before release, and the Maven's support for deploying over svn is limited.  The new maven respository manager will be used to deploy to a temporary staging location over webdav or a secure copy operation.  This would allow each release to be tested before being deployed to the maven2_releases repository.  Nexus allows this to be done through the UI, so there is no additional setup required by users/developers.  Developers will have to use the correct deployment URL to deploy to the repository manager staging environment.

Implementation Roadmap