Using Maven

Author: T. Merabti, P. Guzewicz, M. Mohanty

Maven versioning

Release versions: In Maven, when you deploy a new version of your JAR file, this version will be downloaded only once to the local repository because Maven never re-downloads releases. For this reason, new releases should use a new version number. In other words, when you are using 1.0, once Maven has downloaded this artifact as a release, it never tries to get a new 1.0 from the remote repository.

Snapshot versions: If the project is still under development, you should append -SNAPSHOT to the version name. In this case, Maven will check for updates, and download or re-download the latest version  (see also NOTE below!) from the remote repository to the local. This is possible since snapshots modules are stored with a timestamp.

NOTE: By default, the update interval is daily (one day). So, if the SNAPSHOT jar changes before 24 hrs, Maven may not fetch the latest one! To override this, one can specify -U switch while building (see also below) or specify the updatePolicy to be always in pom.xml.

Using SNAPSHOT versions:

In pom.xml, under <version> tag change the name to version-SNAPSHOT (e.g. 0.0.1-SNAPSHOT).

  1. In the pom.xml, before the closing </build> tag add the <distibutionManagement>…</distibutionManagement> element:
    <build> 
     <distributionManagement> 
      <repository> 
        <id>gitlab-maven</id> 
        <url>https://gitlab.inria.fr/api/v4/projects/46547/packages/maven</url> 
      </repository> 
     </distributionManagement> 
    </build>
  2. The pom.xml of the project which uses a jar from the Maven repository needs to specify how to find it using the following:
    <repositories>
     <repository>
      <id>gitlab-maven</id>
      <url>https://gitlab.inria.fr/api/v4/projects/46547/packages/maven</url>
     </repository>
    </repositories>
  3. Before running mvn deploy, it is important to configure correctly the snapshot server in the project pom.xml and in the settings.xml file.

The settings.xml file under the ~/.m2 directory must contain all connection information to maven repositories. Under the <servers> element add this server.

<?xml version="1.0" encoding="UTF-8"?>
<settings xmlns="http://maven.apache.org/SETTINGS/1.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/SETTINGS/1.0.0 http://maven.apache.org/xsd/settings-1.0.0.xsd">
	<pluginGroups />
	<proxies />
	<servers>
    <server>
      <id>gitlab-maven</id>
      <configuration>
        <httpHeaders>
          <property>
            <name>Deploy-Token</name>
            <value>DEPLOY_TOKEN_VALUE</value>
          </property>
        </httpHeaders>
      </configuration>
    </server>
	</servers>
	<mirrors />
	<profiles>
	<profile>
        <id>profile-cedar-releases</id>
        <activation>
            <activeByDefault>true</activeByDefault>
        </activation>
        <repositories>
            <repository>
              <id>gitlab-maven</id>
              <url>https://gitlab.inria.fr/api/v4/projects/46547/packages/maven</url>
            </repository>
        </repositories>
    </profile>
	</profiles>
</settings>

The Deploy-Token needs to be created from “Deploy Token” section here: https://gitlab.inria.fr/cedar/maven/-/settings/repository. You need write package registry rights to be able to deploy. Save the token password somewhere as it is impossible to retrieve it afterwards.

Deployment

Run mvn -U clean deploy to deploy the new snapshot version in the snapshot repository. Note that the -U switch ensures that you fetch the latest SNAPSHOTs of all the jars.

Update

Run mvn -U clean install to update dependencies in the local repository with the latest snapshot version.

Dependency Hell

In order to avoid any dependency issues, ensure that all the projects use the same version of a library. If this is not the case, Maven tries to resolve it by picking the version specified in the closest project in the tree of dependencies. This is not necessarily the latest or the oldest version! If one specifies explicitly a version in their pom.xml, then this version being the nearest definition takes precedence over all other versions. Different versions in various projects have caused errors in the past, thus, it is advisable to avoid such a situation.

Best practices

Before the deployment of any packages, be sure that the latest dependencies “release and/or snapshot” are in remote repositories.Example: Suppose that you have two maven projects: A and B. Project B is one of the dependencies of project A. Locally, you make some changes in project B and you need to deploy project A. Before the deployment of A in the remote repository you need to deploy the updated version of B first.

More info

We have purchased a “Maven cookbook” physical book which gives more information on things one can do with Maven, and how to do them. Ask Ioana or look around.

Useful commands:

  1. mvn dependency:analyze
    Finds explicit and implicit dependencies in the project and suggests to add or remove dependencies in pom.xml
  2. mvn versions:display-dependency-updates
    Shows the newest versions of your dependencies in pom.xml
  3. mvn versions:display-plugin-updates
    Shows the newest versions of plugins in pom.xml
  4. mvn dependency:tree -Dverbose
    Shows a list of dependencies in a project and their (deep) sources.

Comments are closed.