Well, so you use a repository manager. Now, you need to tell Maven to use it to download all the missing artifacts. Moreover, as an organization, you usually want to control where the artifacts are downloaded from. This means you need to make sure that all developers are using the identical set of repositories for all the projects.
There are two placed you could use to configure your repositories: in the project's POM, or in the
<settings>element on the
settings.xmlfile. This post will discuss both ways and tell you which one you should use ;-)
The "innocent way" is to add a definition like this to your POM:
<repositories>Maven uses all declared repositories to find missing artifacts. If it can't find what it's looking for, Maven will also fall back to the repository central which is defined in the built-in parent POM. However, this is usually not what you want; instead, all artifacts should be proxied by your repository manager.
<name>Company internal repo</name>
This can be prevented by "overloading" the central repository with your own repository manager, i.e. you just add a definition with
When using a central repository manager, the definition of repositories should be the same for all your projects. This is usually done by putting this stuff to a company's base POM. But... if someone is starting in a clean environment, Maven will have to know where the repository is to find the project's parent POM, where it will find where the repository is... you're stuck.
Moreover, any POM that is included by transitive dependencies may specifiy additional repositories which are not redirected like the central repo. These external repositories are used by Maven to find all dependencies, even your internal ones that for sure are not hosted there; and you still do not really control where the artifacts are coming from.
Hence, using POM to define your repositories does not really solve any problem. Just don't do that!
So, we end up with the alternative and recommended way of defining your repositories: the settings.
To really make sure that all developers and all projects are using the identical set of repositories, you should use mirrors to tell Maven to redirect all artifact requests to your internal repository manager.
Both the mirror and repository settings can be defined in the
settings.xmlfile. I think I will do another post to explain what a good setup would look like...
There are two locations for
- the Maven installation at
- the user's local settings:
Actually, both locations require the Maven user (your team members) to manually do some configuration in their setting file. This is general not preferred for the known reasons: everybody needs to do this manually, no automatic update if settings change later on, unexpected behaviour when someone forgets to adopt his/her file etc.
The only way to avoid these drawbacks is to avoid all manual editing work, i.e. provide a central version of the settings file that is checked in to your sourcecode management system (SCM). This can't be done for the second option (user's settings) but it can be done for the first (installation settings) – if you put Maven installation under source control.
This sounds a bit strange at first (after all, it's an executable!) but is really clever IMO, for the following reasons:
- You make sure everybody uses the same version of Maven; no more Maven version dependencies!
- You can use a relative path from your projects to the Maven installation if they are part of the same source repository, for instance in batch files, Eclipse launch configurations etc.
- The correct settings are applied automatically and may be updated in the repository without requiring any editing by the developers (except for updating).
- Maven installation is only around 2 MB of size, which is not really an issue for any SCM.
The Bottom Line
To summarize, by putting your Maven installation in your SCM as part of your project environment, and using central settings to configure Maven to use your repository manager, you reduce dependency to local environment. And stabilizing your builds is always a good thing!