microBean™ Maven CDI

Background and History

The internal Maven machinery for interacting with artifact repositories has gone through several phases of existence.

Its earliest incarnation is in the form of the maven-artifact-resolver artifact, version 1.0, circa 2009 (here in 2019 this artifact should not be used).

This code was subsequently broken out as a standalone project into Sonatype’s Æther project in August 2010.

Sonatype Æther then moved to the Eclipse foundation in August 2014, but never really caught on as a standalone project outside of its original Maven-oriented user base, and was archived in January 2015.

The Sonatype Æther project was handed back to the Maven project and reincarnated as the Maven Artifact Resolver project in January 2017, with an overarching artifact identifier of maven-resolver (not maven-artifact-resolver). Somewhat oddly, the package names have not changed, so the classes provided by the maven-resolver project all start with the org.eclipse.aether. prefix.

This project adapts the maven-resolver project to CDI environments.

Installation

Place this project’s .jar file on your classpath.

How It Works

The maven-resolver project fortunately was written with dependency injection in mind. Specifically, it was written as a Guice module to be used from within Maven proper, which, at least in recent versions, uses Guice under the covers.

The microBean™ Maven CDI project does just enough work to re-express certain Maven Guice components using CDI constructs so that you may simply inject the parts of maven-resolver that you need.

For example, to work with artifact repositories, you’re going to need a RepositorySystem and a RepositorySystemSession. With microBean™ Maven CDI, you simply do this:

@Inject
private RepositorySystem repositorySystem;

@Inject
private RepositorySystemSession repositorySystemSession;

…and the MavenExtension portable extension takes care of setting up the dozens of supporting objects for you behind the scenes.

microBean™ Maven CDI also natively understands your user-level ~/.m2/settings.xml file, and can use it so that you can inject the right remote repositories, even taking its local repository and mirrors settings into consideration:

@Inject
@Resolution // for dependency resolution, as opposed to, say, deployment
private List<RemoteRepository> remoteRepositories;

Usage

Here is some pseudocode showing how you might go about resolving the (arbitrarily chosen for this example) org.slf4j:slf4j-api:1.7.24 artifact from within your CDI bean:

import org.eclipse.aether.RepositorySystemSession;
import org.eclipse.aether.RepositorySystem;

import org.eclipse.aether.artifact.Artifact;
import org.eclipse.aether.artifact.DefaultArtifact;

import org.eclipse.aether.collection.CollectRequest;

import org.eclipse.aether.repository.RemoteRepository;

import org.eclipse.aether.resolution.ArtifactResult;
import org.eclipse.aether.resolution.DependencyRequest;
import org.eclipse.aether.resolution.DependencyResolutionException;
import org.eclipse.aether.resolution.DependencyResult;

import org.eclipse.aether.util.artifact.JavaScopes;

import org.eclipse.aether.util.filter.DependencyFilterUtils;

@Inject
private RepositorySystem repositorySystem;

@Inject
private RepositorySystemSession session;

@Inject
@Resolution
private List<RemoteRepository> remoteRepositories;

public void resolve() throws DependencyResolutionException {
  final CollectRequest collectRequest = new CollectRequest();
  final Artifact artifact = new DefaultArtifact("org.slf4j", "slf4j-api", "jar", "1.7.24");
  collectRequest.setRoot(new Dependency(artifact, JavaScopes.COMPILE));
  collectRequest.setRepositories(remoteRepositories);

  final DependencyRequest dependencyRequest = new DependencyRequest(collectRequest, DependencyFilterUtils.classpathFilter(JavaScopes.COMPILE));
  final DependencyResult dependencyResult = repositorySystem.resolveDependencies(session, dependencyRequest);
  final List<ArtifactResult> artifactResults = dependencyResult.getArtifactResults();
}