Creating a Shared Repository
Most organizations will need to set up one or more shared repositories, since not everyone can deploy to the central Maven repository. To publish releases for use across different environments within their network, organization’s will typically want to set up what is referred to as an internal repository. This internal repository is still treated as a remote repository in Maven, just as any other external repository would be. For an explanation of the different types of repositories, see Chapter 2.
Setting up an internal repository is simple. While any of the available transport protocols can be used, the most popular is HTTP. You can use an existing HTTP server for this, or create a new server using Apache HTTPd, Apache Tomcat, Jetty, or any number of other servers.
To set up your organization’s internal repository using Jetty, create a new directory in which to store the files. While it can be stored anywhere you have permissions, in this example
C:mvnbookrepository will be used. To set up Jetty, download the Jetty 5.1.10 server bundle from the book’s Web site and copy it to the repository directory. Change to that directory, and run:
C:mvnbookrepository> java -jar jetty-5.1.10-bundle.jar 8081
You can now navigate to
http://localhost:8081/ and find that there is a Web server running displaying that directory. Your repository is now set up.
The server is set up on your own workstation for simplicity in this example. However, you will want to set up or use an existing HTTP server that is in a shared, accessible location, configured securely and monitored to ensure it remains running at all times.
This chapter will assume the repositories are running from
http://localhost:8081/ and that artifacts are deployed to the repositories using the file system. However, it is possible to use a repository on another server with any combination of supported protocols including
http, ftp, scp, sftp, and more. For more information, refer to Chapter 3.
Later in this chapter you will learn that there are good reasons to run multiple, separate repositories, but rather than set up multiple Web servers, you can store the repositories on this single server. For the first repository, create a subdirectory called internal that will be available at
This creates an empty repository, and is all that is needed to get started.
C:mvnbookrepository> mkdir internal
It is also possible to set up another repository (or use the same one) to mirror content from the Maven central repository. While this isn’t required, it is common in many organizations as it eliminates the requirement for Internet access or proxy configuration. In addition, it provides faster performance (as most downloads to individual developers come from within their own network), and gives full control over the set of artifacts with which your software is built, by avoiding any reliance on Maven’s relatively open central repository.
You can create a separate repository under the same server, using the following command:
This repository will be available at
To populate the repository you just created, there are a number of methods available:
- Manually add content as desired using mvn deploy:deploy-file.
- Set up the Repository Manager (Archiva) as a proxy to the central repository. This will download anything that is not already present, and keep a copy in your internal repository for others on your team to reuse.
- Use rsync to take a copy of the central repository and regularly update it. At the time of writing, the size of the Maven repository was 5.8G
The Repository Manager (Archiva)1 is a recent addition to the Maven build platform that is designed to administer your internal repository. It is deployed to your Jetty server (or any other servlet container) and provides remote repository proxies, as well as friendly repository browsing, searching, and reporting. The repository manager can be downloaded from http://maven.apache.org/repository-manager/.
When using this repository for your projects, there are two choices: use it as a mirror, or have it override the central repository. You would use it as a mirror if it is intended to be a copy of the central repository exclusively, and if it’s acceptable to have developers configure this in their settings as demonstrated in section 7.2. Developers may choose to use a different mirror, or the original central repository directly without consequence to the outcome of the build.
On the other hand, if you want to prevent access to the central repository for greater control, to configure the repository from the project level instead of in each user’s settings (with one exception that will be discussed next), or to include your own artifacts in the same repository, you should override the central repository.
To override the central repository with your internal repository, you must define a repository in a settings file and/or POM that uses the identifier central. Usually, this must be defined as both a regular repository and a plugin repository to ensure all access is consistent. For example:
<repositories> <repository> <id>central</id> <name>Internal Mirror of Central Repository</name> <url>http://localhost:8081/central/</url> </repository> </repositories> <pluginRepositories> <pluginRepository> <id>central</id> <name>Internal Mirror of Central Plugins Repository</name> <url>http://localhost:8081/central/</url> </pluginRepository> </pluginRepositories>
Repositories such as the one above are configured in the POM usually, so that a project can add repositories itself for dependencies located out of those repositories configured initially. However, there is a problem – when a POM inherits from another POM that is not in the central repository, it must retrieve the parent from the repository. This makes it impossible to define the repository in the parent, and as a result, it would need to be declared in every POM. Not only is this very inconvenient, it would be a nightmare to change should the repository location change!
The solution is to declare your internal repository (or central replacement) in the shared
settings.xml file, as shown in section 7.2. If you have multiple repositories, it is necessary to declare only those that contain an inherited POM.
It is still important to declare the repositories that will be used in the top-most POM itself, for a situation where a developer might not have configured their settings and instead manually installed the POM, or had it in their source code check out.
The next section discusses how to set up an “organization POM”, or hierarchy, that declares shared settings within an organization and its departments.