Automation Series #9 – Dealing with Repositories

It’s time to cover from where Maven extracts all libraries and how we can change it to fulfill our projects’ needs. Most of the cases, the default configuration will be enough. But knowing how a different remote or an internal repository is configured will be essential to master any Maven project.

Repositories

Although it may look complicated, there are only two types of repositories: local and remote.

local: used to cache all remote downloads and store artifacts not yet released.
remote: any repository accessed by protocols like file:// and http://.

The local repository is located at <user_home>/.m2/repository/. It’s used only for cache purpose and have exactly the same folder structure as the Central Repo (Source Code Management – SCM). If you are running out of disk space, you can delete this folder knowing that part of it will be downloaded again according to projects usage.

Next to the files, there are also the javadoc and source code from each library if it is available. It may help a lot to search for a specific piece of code from a framework. Most of the IDEs have this integration by default to smoothen this access.

Maven Default

As we already know, Maven provides a base configuration to download dependencies and plugins. You can recap how to check your effective-pom at this article.

[...]
<repositories>
  <repository>
    <snapshots>
      <enabled>false</enabled>
    </snapshots>
    <id>central</id>
    <name>Central Repository</name>
    <url>https://repo.maven.apache.org/maven2</url>
  </repository>
</repositories>
<pluginRepositories>
  <pluginRepository>
    <releases>
      <updatePolicy>never</updatePolicy>
    </releases>
    <snapshots>
      <enabled>false</enabled>
    </snapshots>
    <id>central</id>
    <name>Central Repository</name>
    <url>https://repo.maven.apache.org/maven2</url>
  </pluginRepository>
</pluginRepositories>
[...]

Maven uses the same place to store dependencies and plugins. You can check the complete path of any library from your browser. Try it out.

repositories: Handle only dependencies.
pluginRepositories: Handle only plugins.
releases: Allow downloading RELEASE types. By default the value is true.
snapshot: In this case, SNAPSHOTs are not allowed for download.
updatePolicy: The frequency for downloading updates. Never to plugins (super pom configuration) and daily (default value) to dependencies.

Custom Repositories

It is not very common but sometimes you need a library which isn’t at Maven Central. One of the ways is to configure a different repository.

Let’s take as an example the spring-webmvc. At this moment the latest release is 5.0.1.RELEASE according to Maven Central. But if we want to use a development snapshot version, how can we do this?

Spring has a specific repository to handle snapshot versions.

To be able to test the 5.0.2.BUILD-SNAPSHOT we need to set the Spring repository configuration.

[...]
  <dependency>
      <groupId>org.springframework</groupId>
      <artifactId>spring-webmvc</artifactId>
      <version>5.0.2.BUILD-SNAPSHOT</version>
  </dependency>
</dependencies>

<repositories>
  <repository>
    <id>spring-snapshot</id>
    <name>Spring Maven SNAPSHOT Repository</name>
    <url>https://repo.spring.io/snapshot</url>
    <snapshots>
      <enabled>true</enabled>
    </snapshots>
    <releases>
      <enabled>false</enabled>
    </releases>
  </repository>
</repositories>
[...]

Now we have allowed only snapshot downloads from Spring repository. But notice that we still allowing any release versions from Central as the default configuration.

Source Code Management

Behind this great Maven Central repository, there is a great software to handle every operation. It is Nexus, an Open Source project from Sonatype that can also be installed as your internal repository. We may cover this topic in another time. But if you are curious and want to download it now, here is the link.

Another big player on repository management is JFrog Artifactory that also has an Open Source version. Here is the link if you want to try.

Both have professional versions with greater support and exclusive features for an enterprise point of view.

Next Step

That’s the end of automation build series covering the base concepts of Maven. But we can still solve many problems around.

What is your biggest challenge to apply an automatic build to your project?

The next Maven articles will cover real problems that YOU want to know. Send me an email (rcmoutinho@cyborgdeveloper.tech) or ping me on Twitter @rcmoutinho.

Let’s automate!