Nexus 3 OSS as a Maven and Gradle repository to win time or “How dev nomads work offline”

In this process, we’ll set up a Nexus 3 OSS Docker compatible with both AMD and Apple Silicon platforms and configure Gradle to use Nexus as a central repository of plugins and Maven dependencies.

WHY

Let’s start by answering why we might want to have a dependency cache server or dedicated dependency repository. Few popular reasons for that:

1. To reduce the building time. Nowadays almost everything is wrapped into containers to isolate building processes from side effects. The drawback of it is downloading all dependencies every time we build a Docker image or create a container.
2. Network traffic / offline work. Lots of techies work remotely, some do coding in an environment where poor cell network coverage or without it during traveling or flights. Even for a small project dependencies can easily take over 100Mb for each building, depending on the language and framework you use.
3. Enhanced Dependency Control. Gain better control over dependencies it is a common goal in projects where updates roll out frequently. It requires that your development teams have consistent access to required dependencies.
4. Security policy. There are plenty of InfoSec requirements and restrictions that might be applied: no inbound or outbound traffic allowed etc.

HOW

There are many ways to deal with cache: using features provided by Maven, Gradle, NPM, and other build automation software, and mounting volumes in Docker to reuse downloaded dependencies. As an option, you can also implement caching proxy server using Nginx. Still, more is needed to cover the demands from the list above.

The point of this article is to show how to build your dependency repository with anonymous access in minimum time and effort.

NEXUS

Nexus Repository by Sonatype it’s one of the most popular repository management systems that has an open-source version which we will use.

ARM specific: Official Docker image of Nexus 3 has only Linux/amd64 architecture option. Though it works on MacOS with M1/M2 processors however this way Docker uses Rozetta which slows down the performance. Still, we can run it specifying --platform param with Linux/amd64 value.

The base image is Universal Base Image (UBI) by Red Hat which supports both ARM and AMD so we can use it for distribution across the teams.

Nexus provides a source Dockerfile at their Github repo so we can use it and wrap it into docker-compose.yaml

version: '3.8'
services:
  my_nexus:
    build:
      context: nexus3
      dockerfile: Dockerfile
    ports:
      - "8081:8081"
    volumes:
      - ~/nexus3-data:/nexus-data

or append params to the docker build/run commands e.g.:

docker build -t my_nexus_image nexus3
docker run -d -p 8081:8081 -v ~/nexus3-data:/nexus-data my_nexus_image

We map the container’s folder /nexus-data onto the host’s home directory ~/nexus3-data so if you re-create the container or drop it to rebuild the image and run to update its version your cache and configuration are persisted at your host machine and will be reused.

After you run it can take up to a few minutes depending on available resources until Nexus web GUI will be ready on the specified port (http://locahost:8081).

The main page of the web console for non authorized users

In our case, the initial admin password is available in file ~/nexus-data/admin.password

API

Besides web-console Nexus exposes a pretty rich API which helps to customise and automate related workflow if needed. Swagger UI is available after authorization:

Swagger UI when authorized as admin or user with the proper role

System resources: basically it takes 2Gb of memory to run it but there are well-detailed recommendations and guidelines at Sonatype's official website for different scenarios.

REPOSITORIES

Nexus 3 supports plenty of popular repository formats for modern solutions that manage dependencies or use registries: APT, Yum, Docker, npm, Bower, Maven, Go, Helm, R, PyPI, CocoaPods, and even the RAW format that does not enforce any type of layout. Nexus also has the option to configure BLOB stores compatible with AWS S3 if required.

SAMPLE

For the showcase let’s consider a simple web service based on Spring Boot 3, Java 17, and Gradle. It is not necessary for us to know what the service does but we want to make it fetch dependencies from Nexus 3 repository. Every building tool has guides on how to override dependency resolve configuration and Gradle has it too.

Gradle can be configured with Groovy-DSL (old style) or Kotlin-DSL. In this example, Gradle’s Groovy DSL is used because it is still the most popular.

Gradle repository configuration for Maven dependencies and Gradle plugins

In the code snippets above the logic is simple: if the environment variable NEXUS_URL is defined or CLI argument NEXUS_URL was passed, Gradle has to use it to override the default repository URL.

Maven dependencies repository configuration is placed in build.gradle. In a multi-project structure, you get build.gradle per sub-project but there are ways to move common code to the root project to avoid duplication.

Gradle plugins repository is defined in settings.gradle which is common for the whole Gradle project.

Logs of docker-compose from the sample project

If you passed the parameter properly it will be visible in the logs that Gradle downloads dependencies from the presented URL.

DEPLOY

It can be different options depending on the goal.

• Local dev environment — to develop, build, and test apps offline or during an unstable/slow internet connection.
• Cloud — if the dependency management process is part of CI, InfoSec, or any kind of corp policy. It can be deployed on AWS or any other VPS vendor such as GCP, Azure, Hetzner, or Cloud Ocean including on-premise.

SOURCES

For this article, I created a dedicated repository with a demo application: https://github.com/antukhov/gradle-nexus3/tree/main

Feel free to reach out if any questions related to this topic are unresolved after research with Stackoverflow and ChatGPT :]