In last article we learnt 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 artefacts are stored and maintained for future retrieval. The repositories used by maven or the 'maven repositories' are the locations used to store the maven artefacts. Maven artefacts are stable components bundeled together and put in the central location to be used by different maven builds. Maven itself knows the structure of maven repositories in order to acquire the artifacts needed by the current build but does not have direct access to. For eg: 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.

Remote

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

Local

This is the repository on you 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 local repository to build on local machine. All the artefacts that Maven need are downloaded from the remote repository. localRepository tag in the setting.xml file specifies the location of local repository on the machine as specified in the following snippet.

... /path/to/local/repository > ...

Release and snapshot

Release and snapshot repositories are typically used to specify which artefacts are under development and which artifacts are stable, released and being used in production. For eg: If your organisation 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.

Internal and external repositories

Any repository which uses the artefacts confined only to the project it is in is called internal repository. Anything outside the project is call external repository.

Why Deployment?

Whenever you make any changes in any of the components/artefacts 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

      -Durl=scp://HOST:PATH
      -DrepositoryId=REPO_ID
      -DpomFile=POM_FILE
      -Dfile=FILE_TO_DEPLOY

While using mvn deploy, you need to be aware that it should always be called from the directory where pom.xml for 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 deployement, if you get 401 error this means your user name is not part of the artifactory users group.Get your self added to the correct users group. Make sure you correct the username and password is in the settings.xml file. Also even after the user is added and you get 'Authorization failed' error this could mean that you can actually log into the repository but do not have rights/permissions to view/deploy files. What should I do to mantain different versions:

Sometimes you might want to mantain different versions of your artefacts then you could follow this process.

• Check that there are no uncommitted changes in the sources
• Change the version in the poms from x-SNAPSHOT to a new version.
• Do mvn deploy
• Run the tests to make sure everything is correct and the changes are getting pulled down as expected.
• Then commit the new POM files
• 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.