Introduction to Maven Repositories

Posted on Posted in Software Testing, Test Automation, Tools

In the last article, we learned about using Hudson to run the Selenium tests on different machines and different browsers using maven builds. This week we would explain what are maven repositories and different operations which can be performed using these repositories. Most often than not, we develop common libraries for automation which needs to be shared across different projects. This article will touch upon how repositories can be used to utilized common libraries in different projects.

Why Repository?

A repository is a place where data or artifacts are stored and maintained for future retrieval. The repositories used by maven or the ‘maven repositories’ are the locations used to store the maven artifacts. Maven artifacts are stable components bundled together and put in the central location to be used by different maven builds. Maven itself knows the structure of maven repositories to acquire the artifacts needed for the current build but does not have direct access to. For, e.g., The project testingGeek-tests(the automated tests for the TestingGeek) is making use of some common libraries which are part of another class/package testingGeek-commons. But this class is not part of the testingGeek-tests project. The best way to use testingGeek-commons package is to publish/deploy it to the central repository so that it could be downloaded whenever it is needed by testingGeek-tests maven build.

Types of Repositories

There are different types of repositories based on location, version, and projects.

1. Remote: A remote repository is a file system hosted by a web server that provides download access to the artifacts it contains.

2. Local: This is the repository on your local machine and specified in the settings.xml file in the .m2 directory. Location of .m2 directory will vary according to your installation, but be aware that this will be a hidden directory. Maven does not build on the remote repository and uses a local repository to build on a local machine. All the artifacts that Maven need are downloaded from the remote repository. localRepository tag in the setting.xml file specifies the location of a local repository on the machine as specified in the following snippet.

/path/to/local/repository >

3. Release and snapshot: Release and snapshot repositories are typically used to specify which artifacts are under development and which artifacts are stable, released and being used in production. For, e.g., If your organization is using some component which is under development then the repository version is the snapshot and once you have tagged and released it could be in the released repository.

4. Internal and external repositories.: Any repository which uses the artifacts confined only to the project it is in is called internal repository. Anything outside the project is called external repository.

Why Deployment?

Whenever you make any changes in any of the components/artifacts which are part of the repository (Maven build), then you need to publish it. Otherwise, changes might not be visible. You need to publish these changes because subversion (or any SCM) repositories and Maven repositories are different. When we commit our changes, we make changes in the SCM repository, but maven build uses Maven internal repository location. There is no way for the maven repository to know that something has changed in the SCM repository unless you ‘publish’ the changes or deploy the changes to the repository. Maven uses a simple command to publish these changes

mvn deploy

This will deploy the entire project to the repository mentioned in the settings.xml file but if you want to deploy specific files you could use this command.

mvn deploy:deploy-file


While using mvn deploy, you need to be aware that it should always be called from the directory where pom.xml for the project is present. This command will read the repository location and name from your POM file as well as from the settings.xml file.

During deployment, if you get 401 error this means your user name is not part of the artifactory user group.Get yourself added to the correct user group. Make sure you correct the username and password are in the settings.xml file. Also even after the user is added and you get ‘Authorization failed’ error this could mean that you can log into the repository but do not have rights/permissions to view/deploy files.

What should I do to maintain different versions:

Sometimes you might want to maintain different versions of your artifacts then you could follow this process.

1. Check that there are no uncommitted changes in the sources
2. Change the version in the poms from x-SNAPSHOT to a new version.
3. Do mvn deploy
4. Run the tests to make sure everything is correct and the changes are getting pulled down as expected.
5. Then commit the new POM files
6. Make sure this new snapshot version is changed in all the other Pom file of the project as well.

Hope you found this primer on MVN, repositories and deployment useful.

Please follow and like us: