In a corporate environment it makes sense to have some control over the setup of Maven.
- restricting dependencies to approved versions of artifacts
- reducing network bandwidth by having a maven repository proxied
- sharing corporate assets by deploying them centrally
These scenarios can be realized by using internal Maven repositories and a Maven proxy. Be very careful not to confuse these two concepts as both services are often located on the same physical machine and it is easy to get them mixed up.
This guide will recommend installing both the Maven internal repositories and the Maven proxy on a single machine and to make this guide a bit more readable this machine will be called NUCLEUS.
To get an overview of repositories please read http://maven.apache.org/guides/introduction/introduction-to-repositories.html
For another example of repository setup with diagrams showing this configuration see http://cvs.peopleware.be/training/maven/maven2/repositories.html
Definitions of Repositories
A repository holds Maven artifacts in a well defined directory structure.
The purpose of the repository influences the types of resources that are stored in that repository.
The following list attempts to define the different terms used when discussing different repository types.
The directory structure on your local machine which stores all the artifacts required by all the projects on your system.
It is a cache of artifacts from remote repositories for any mvn command you have run.
A remote repository is where the user may get artifacts from. A remote repository can be located anywhere and accessed by any protocol supported by Wagon (ftp/scp/http/file/...)
A remote repository inside your firewall, i.e. a repository not on your machine but in the confines of your organization.
You might have internal release/snapshot repositories as well.
Same as #internal repository.
A special remote repository which is situated at http://www.ibiblio.org/maven2/.
This remote repository is where most open source software artifacts are located.
A release repository is a remote repository specifically for housing released code.
No snapshots should be stored in this repository.
A snapshot repository is a remote repository specifically for housing non-release code as snapshots should not be stored with released artifacts.
Creating the repositories
Creating a Maven proxy
Maven Proxy Choices
In no particular order:
maven-proxy http://maven-proxy.codehaus.org/ (outdated and no longer actively worked on)
Proximity http://proximity.abstracthorizon.org/, which comes preconfigured for corporate or personal use. It is packaged as J2EE WAR file and is deployable by simply dropping it on Apache Tomcat or any other J2EE servlet container.
Artifactory http://artifactory.sf.net, an enterprise proxy and repository manager, that is a complete new rewrite of maven-proxy. Artifactory runs out-of-the-box on a lightweight Jetty server and can also be deployed on a standard servlet container as WAR file.
Though not yet released, Maven Archiva also provides proxy support. It is available at http://maven.apache.org/archiva/.
Another project which only offers a proxy (with very limited support to simulate a company repository server) is DSMP (Dead Simple Maven Proxy) at http://www.pdark.de/dsmp/. It's means to simplify the handling of Maven mirrors, inject patches for buggy/broken releases on the official sites and to allow aggregate several sites in a controlled way (for example, you can specify rules to allow to use specific SNAPSHOT versions for a single plugin without polluting your local or company repository with SNAPSHOT's).
If you need to have a proxy and still share your artifacts with other people in your team/company, install Proximity, Artifactory or Archiva as a site wide repository server and DSMP to connect Maven with the Internet.