blob: 5035cb1d55f510a8db3005d6aa7891095630756b [file] [log] [blame]
dt {
display: list-item;
list-style-position: outside;
margin-left: 16px;
dd {
margin-left: 25px;
margin-bottom: 5px;
The Aether project is a proposed open source project under the <a
Container Project</a>.
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 <a
Proposals</a> Forum.
<p>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
<p>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.</p>
<p>The primary task of Aether is to resolve transitive
dependencies. This task can be split into two sub tasks:</p>
<li>Determine the coordinates of the artifacts that make up the
transitive dependencies.</li>
<li>Resolve the files for the artifacts that have been identified
in step 1.</li>
<p>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.</p>
Starting from a given root dependency like <a
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
<p>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.</p>
<p>So more technically, the dependency graph that the repository
system returns to its caller is affected by instances of
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.</p>
<p>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.</p>
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 <a
Aether in Maven Plugins</a> for the actual code bits.
There's also a <a
Class Diagram</a> that illustrates a subset of the API graphically.
<h2>Relationship with other Eclipse projects</h2>
<p>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.</p>
<h2>Why Eclipse?</h2>
Answer these two questions: What value does this project bring to the Eclipse
community? What value do you expect to obtain from hosting your project at Eclipse?
What value do you get by having your project at Eclipse over and above the value
of hosting at Eclipse Labs?
<p>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.</p>
<p>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.</p>
<h2>Initial Contribution</h2>
The initial contribution of the Aether would consist of the core
codebase that can be viewed <a
href="">here</a> and the
Aether Ant Tasks which can be viewed <a
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.
<h2>Legal Issues</h2>
<p>There are no known legal issues.</p>
<p>The following individuals are proposed as initial committers to
the project:</p>
<li>Benjamin Bentmann, Sonatype (lead)</li>
<li>Jason van Zyl, Sonatype (lead)</li>
<li>Igor Fedorenko, Sonatype</li>
<li>Benjamin Hanzelmann, Sonatype</li>
<li>Jeanfrancois Arcand, Sonatype</li>
<li>Alin Dreghiciu, Sonatype</li>
<li>Herve Boutemy</li>
<li>Kristian Rosenvold</li>
<li>Stephen Connolly</li>
<li>Olivier Lamy (Talend)</li>
<li>Mark Struberg</li>
<li>Brian Fox (Sonatype)</li>
<li>John Casey (Red Hat)</li>
<p>The following Architecture Council members will mentor this
<li>Mik Kersten</li>
<li>Wayne Beaton</li>
<h2>Interested Parties</h2>
<p>The following individuals, organisations, companies and projects
have expressed interest in this project:</p>
<li>Christophe Thiebaud, SAP</li>
<li>Louis Lecaroz, SAP</li>
<li>Andreas Brehmer, SAP</li>
<li>Dain Sundstrom, Proofpoint</li>
<h2>Project Scheduling</h2>
<p>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.</p>
<h2>Changes to this Document</h2>
<td>Added several new committers</td>