2.1 Configure Maven to use Nexus

In Track 2 you configure Maven to retrieve a library from this cluster’s Nexus repository, then select its exact remediated version from a workshop vulnerability record. You work in one prepared Gitea clone in the Showroom terminal. This module establishes the repository and starting version; module 2.2 changes the version. Track 3 commits that choice to your application.

Why this control exists

An enterprise artifact manager gives developers and builds one place to retrieve approved dependencies. Lightwell publishes Validated and Remediated channels. Validated follows the upstream release; Remediated provides an exact security-backport version on that release line. A Maven coordinate, or GAV, identifies the group, artifact, and version: org.apache.commons:commons-lang3:3.14.0.

Settings profiles point to Nexus channels while the POM identifies a library version; Nexus serves seeded artifacts or proxies upstream according to provisioning mode
Figure 1. Maven settings selects the repository; the POM selects the version.

Your Maven request goes to Nexus in namespace lightwell-repo. In the default seeded mode, provisioning has uploaded the workshop artifacts there. In proxy mode, Nexus retrieves artifacts from Lightwell. Both modes expose the same channel names. This exercise demonstrates repository configuration and version selection with workshop data; it does not independently verify an artifact’s signature or security fix.

Learning objectives

By the end of this module, you will be able to:

  • Construct the Validated and Remediated repository URLs from cluster configuration.

  • Complete Maven settings and resolve the starting dependency through Nexus.

  • Distinguish a resolved version from evidence of its download source.

  • Describe the equivalent enterprise-proxy pattern for Python and Artifactory.

Clone the prepared dependency repository

During provisioning of the workshop materials, the workshop developers’ automation created workshop-templates/lightwell-dependencies on the in-cluster Gitea server. The starter contains settings.xml with two URL placeholders, a small pom.xml using Commons Lang 3.14.0, and a workshop advisory for module 2.2. WORKSHOP_REVISION identifies the workshop commit that supplied all three files.

During this lab, you create a local clone containing the settings.xml and pom.xml files. Clone the repository only the first time you start this lab. If you return later, continue in ~/lightwell-dependencies, where your edits and saved command output remain.

DEPENDENCIES_REPO_URL="$(oc -n gitea get configmap lab-gitea -o jsonpath='{.data.lightwell_dependencies_repo_url}')"
DEPENDENCIES_REPO_BRANCH="$(oc -n gitea get configmap lab-gitea -o jsonpath='{.data.lightwell_dependencies_repo_revision}')"
cd ~
git clone --branch "$DEPENDENCIES_REPO_BRANCH" "$DEPENDENCIES_REPO_URL" lightwell-dependencies
cd ~/lightwell-dependencies
cat WORKSHOP_REVISION
ls settings.xml pom.xml advisories/LW-DEMO-0002.json
mvn --version

If the repository or Maven is missing, ask the instructor to repair provisioning. The template is readable within the lab. Edit locally; application ownership and pushing to your own repository belong to Track 3.

Read the Nexus coordinates

ConfigMap lab-lightwell-repo in namespace lightwell-repo supplies the cluster-specific host and repository names. The command below displays the Nexus URL, the Validated and Remediated repository names, and the repository mode, each on a separate line. Check that each field has a value.

oc -n lightwell-repo get configmap lab-lightwell-repo \
  -o jsonpath='nexus={.data.nexus_url}{"\n"}validated={.data.channel_validated}{"\n"}remediated={.data.channel_remediated}{"\n"}mode={.data.lightwell_repo_mode}{"\n"}'

Construct each repository URL as nexus_url/repository/channel_name/, using one slash between each part. The two URLs share a host and use different channel names. Provisioning handles upstream access; do not add Lightwell membership credentials to settings.xml or any other file in your cloned ~/lightwell-dependencies repository.

Exercise

Open ~/lightwell-dependencies/settings.xml in your terminal editor. Replace REPLACE_ME_VALIDATED_URL with the Validated URL you constructed and REPLACE_ME_REMEDIATED_URL with the Remediated URL. Keep both profiles and their repository IDs. You will select one profile explicitly for each Maven run.

The diff should show changes to only the two URL lines, both pointing to your cluster’s Nexus host.

cd ~/lightwell-dependencies
git --no-pager diff -- settings.xml

Resolve and record the starting version

Use a fresh cache so Maven prints the download source instead of reusing an older local artifact. The command below creates a new evidence directory and a separate cache for this attempt. Keep the original evidence when repeating the exercise. Maven may retrieve its plugins from Central; inspect the download for commons-lang3, not an unrelated plugin. Restricting all build fetches belongs to Track 4.

The resolve goal downloads the dependency JAR; tree alone may fetch only its POM. Require a download line ending in the selected .jar, not just .pom.

When the command completes, look for BUILD SUCCESS and org.apache.commons:commons-lang3:jar:3.14.0 in the dependency tree. Confirm that a Downloaded from lightwell-java-validated line shows this artifact coming from your Nexus URL.

cd ~/lightwell-dependencies
mkdir -p evidence
BEFORE_DIR="$(mktemp -d "$PWD/evidence/validated.XXXXXX")"
printf '%s\n' "$BEFORE_DIR" > evidence/current-before
mvn -B -s settings.xml -f pom.xml \
  -Dmaven.repo.local="$BEFORE_DIR/m2" -Plightwell-validated \
  org.apache.maven.plugins:maven-dependency-plugin:3.7.0:resolve \
  org.apache.maven.plugins:maven-dependency-plugin:3.7.0:tree \
  > "$BEFORE_DIR/maven.log" 2>&1
MAVEN_STATUS=$?
cat "$BEFORE_DIR/maven.log"
printf 'Maven exit status: %s\n' "$MAVEN_STATUS"

Review

Read the exit status and log before continuing. A nonzero exit status means the Maven run failed. A dependency-tree line proves which version Maven selected; a successful download line identifies its source. Require both pieces of evidence. If Commons Lang downloads from Central, correct the repository configuration and repeat with a new cache. BUILD SUCCESS alone is insufficient.

The starting version is intentionally affected in the workshop advisory. Successful resolution means Maven could retrieve it, not that it is remediated. Keep settings.xml, the unchanged POM, and the saved evidence for 2.2 Select and verify the remediated dependency.

Applying this pattern elsewhere

A customer artifact manager proxies https://packages.redhat.com/lightwell/java/validated and https://packages.redhat.com/lightwell/java/remediated. Developers and CI use the manager’s URLs in Maven settings. This workshop uses seeded Nexus so the exercise does not require a live Lightwell membership.

Artifactory uses remote Maven repositories exposed through a virtual repository. Python uses pip.conf to select an enterprise package index. These are equivalents of the repository configuration you completed; the hands-on exercise remains Java and Nexus. A Clearinghouse artifact also uses the enterprise manager. See Lightwell concepts for the publication lifecycle.

Official documentation

For customer delivery, see Verify supplier provenance for a real Java dependency. That separate control checks a real JAR against its supplier bundle and trusted key; the seeded fixture makes no such provenance claim.