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 repositoriesand 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
repositories in settings.xml
Defining repositories in settings.xml does not appear to be the ideal way to do this.
Internal repositories should be defined in pom.xml. If this is done in the parent pom it will be inherited for all modules.
I originally put it into settings.xml so that each project would not have to define the internal repositories but it makes more sense for the project to authoratively declare where the repositories are and this has the benefit of reducing the duplication for every developer into their settings.xml.