Skip to main content

Aether

Aether

The Aether project is a proposed open source project under the Technology Container Project.

This proposal is in the Project Proposal Phase (as defined in the Eclipse Development Process) and is written to declare its intent and scope. We solicit additional participation and input from the Eclipse community. Please send all feedback to the Eclipse Proposals Forum.

Scope

The Aether project provides a general-purpose artifact resolution mechanism that can be embedded in any Java program. The Aether project also provides Ant Tasks that allow Ant builds to have the exact same dependency management capabilities as Maven 3.x. The Aether project does not providing any UI related to dependency management.

Description

Aether is a library for working with artifact repositories. Aether deals with the specification of local repository, remote repository, developer workspaces, artifact transports, and artifact resolution. Aether's primary implementation is for Maven repositories and is the resolution engine used in Maven 3.x.

The primary task of Aether is to resolve transitive dependencies. This task can be split into two sub tasks:

  • Determine the coordinates of the artifacts that make up the transitive dependencies.
  • Resolve the files for the artifacts that have been identified in step 1.

Artifacts and their dependencies among each other form a dependency graph. So in other words, step 1 means to calculate this dependency graph and step 2 is a simple graph traversal that fetches the file for each artifact in the dependency graph. In Aether, this dependency graph can be easily inspected and extension points are provided to allow for more control over the construction of the dependency graph. To understand those extension points, we will have a closer look at the way the dependency graph is constructed.

Starting from a given root dependency like org.sonatype.aether:aether-impl:1.7, the repository system first reads the corresponding artifact descriptor (i.e. the POM). The artifact descriptor tells about direct dependencies, dependency management and additional remote repositories to consider during the resolution. For each direct dependency, a dependency selector is given a chance to exclude the dependency from the graph. If the dependency is included, a dependency manager applies dependency management (if any). Next, the declared dependency version is expanded to a list of matching versions from the repositories. For a simple version like "1.0", the resulting list contains only that version. For a version range like "[1.0,2.0)", the version list generally contains multiple versions. For each matching version of the dependency, a child node is added to the dependency graph. Recursion of the process for each child dependency is controlled by a dependency traverser.

The above process creates a dependency graph that often contains duplicate or conflicting dependencies and as such is called a dirty graph. A chain of dependency graph transformers is then used to trim this graph down and to form the resolved dependency graph.

So more technically, the dependency graph that the repository system returns to its caller is affected by instances of org.sonatype.aether.collection.DependencySelector, org.sonatype.aether.collection.DependencyManager, org.sonatype.aether.collection.DependencyTraverser and org.sonatype.aether.collection.DependencyGraphTransformer. Users of the repository system can directly control those extension points when creating the repository system session by providing implementations that fit their needs.

For example, a dependency selector can process exclusions on child dependencies, exclude optional dependencies or dependencies with certain unwanted scopes. A dependency traverser can be used to decide whether the dependencies of a (fat) WAR should be included in the dependency graph or not. Dependency graph transformers can identify and mark conflicting nodes in the dirty tree and resolve conflicting versions or scopes by pruning unwanted parts from the graph.

The class MavenRepositorySystemSession from maven-aether-provider provides a session that mimics the resolution rules used by Maven. In case you want to customize the graph construction, feel free to have a look at the source of its constructor to learn about the implementation classes being used there to achieve Maven style behavior, you might want to reuse some of those for your own repository system session as well. Maven plugins can easily get access to the current repository system session via the usual parameter injection, see Using Aether in Maven Plugins for the actual code bits.

There's also a UML Class Diagram that illustrates a subset of the API graphically.

Relationship with other Eclipse projects

Aether has a lot of alignment with m2eclipse, Tycho, Buckminster and p2. Aether is used heavily within m2eclipse and from within Tycho to make Maven artifacts available to OSGi builds. Buckminster has many artifact resolution, and artifact related uses cases. Of particular interest to Aether developers is the concept of the Buckminster Omni Version that tries to provide interoperability between Maven-based versions and OSGi-based versions. The p2 project has its own artifact resolution mechanism and ultimately if Maven-based resolution can be encoded using SAT4J and resolved using p2 then that would be ideal.

Why Eclipse?

Maven appears to be increasing in importance within the Eclipse community: the Maven 3.x Tycho plugins are rapidly becoming the de facto choice for builds, and m2eclipse is one of the most popular plugins for Indigo. Aether currently plays a vital role within Tycho and m2eclipse and providing access to Aether to those parties who are interested in Tycho and m2eclipse helps build the collaboration between the projects. A greater understand of Aether is generally of value for systems that integrate Maven technologies as Tycho and m2eclipse do. There are a number of companies who are interested in working on Aether, but in particular the Aether project looks forward to the participation of SAP. SAP has been an enormous help on the Tycho project and they have shown a similar interest in working on Aether. We believe that over time many companies leveraging Eclipse-based technologies will be interesting in participating in the Aether project, SAP alone makes the move to Eclipse worthwhile.

Tycho and m2eclipse are already projects heavily in use within Eclipse and Aether is already production ready. The Aether feels that Eclipse proper is a more appropriate place for Aether at its stage of maturity than Eclipse Labs.

Initial Contribution

The initial contribution of the Aether would consist of the core codebase that can be viewed here and the Aether Ant Tasks which can be viewed here. The implementation of the Maven 3.x connector and resolution mechanism is complete and the Aether Ant Tasks are also complete. Inside the core a transport based on Jeanfrancois Arcand's Async HTTP Client is also included. Currently Aether itself does not depend on any Maven 3.x implementation classes, but the first connector implemented is the Maven 3.x connector which allows Maven 3.x to use Aether for all its dependency resolution.

Legal Issues

There are no known legal issues.

Committers

The following individuals are proposed as initial committers to the project:

  • Benjamin Bentmann, Sonatype (lead)
  • Jason van Zyl, Sonatype (lead)
  • Igor Fedorenko, Sonatype
  • Benjamin Hanzelmann, Sonatype
  • Jeanfrancois Arcand, Sonatype
  • Alin Dreghiciu, Sonatype
  • Herve Boutemy
  • Kristian Rosenvold
  • Stephen Connolly
  • Olivier Lamy (Talend)
  • Mark Struberg
  • Brian Fox (Sonatype)
  • John Casey (Red Hat)

Mentors

The following Architecture Council members will mentor this project:

  • Mik Kersten
  • Wayne Beaton

Interested Parties

The following individuals, organisations, companies and projects have expressed interest in this project:

  • Christophe Thiebaud, SAP
  • Louis Lecaroz, SAP
  • Andreas Brehmer, SAP
  • Dain Sundstrom, Proofpoint

Project Scheduling

The Aether project intends to make the first code contribution by August 15th, and we hope for the first builds to be available soon after that.

Changes to this Document

Date Change
18-August-2011 Added several new committers

Back to the top