| <html> | |
| <head> | |
| <title>Aether</title> | |
| </head> | |
| <style> | |
| dt { | |
| display: list-item; | |
| list-style-position: outside; | |
| list-style-image: | |
| url(/eclipse.org-common/themes/Phoenix/images/arrow.gif); | |
| margin-left: 16px; | |
| } | |
| dd { | |
| margin-left: 25px; | |
| margin-bottom: 5px; | |
| } | |
| </style> | |
| <body> | |
| <p> | |
| The Aether project is a proposed open source project under the <a | |
| href="http://www.eclipse.org/projects/project_summary.php?projectid=technology">Technology | |
| Container Project</a>. | |
| </p> | |
| <p> | |
| 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 | |
| href="http://www.eclipse.org/forums/eclipse.proposals">Eclipse | |
| Proposals</a> Forum. | |
| </p> | |
| <h2>Scope</h2> | |
| <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 | |
| management.</p> | |
| <h2>Description</h2> | |
| <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> | |
| <ul> | |
| <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> | |
| </ul> | |
| <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> | |
| <p> | |
| Starting from a given root dependency like <a | |
| href="http://aether.sonatype.org/using-aether-in-maven-plugins.html">org.sonatype.aether:aether-impl:1.7</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 | |
| traverser. | |
| </p> | |
| <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.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.</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> | |
| <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 | |
| href="http://aether.sonatype.org/using-aether-in-maven-plugins.html">Using | |
| Aether in Maven Plugins</a> for the actual code bits. | |
| </p> | |
| <p> | |
| There's also a <a | |
| href="http://aether.sonatype.org/uml-class-diagram.html">UML | |
| Class Diagram</a> that illustrates a subset of the API graphically. | |
| </p> | |
| <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> | |
| <p> | |
| The initial contribution of the Aether would consist of the core | |
| codebase that can be viewed <a | |
| href="https://github.com/sonatype/sonatype-aether">here</a> and the | |
| Aether Ant Tasks which can be viewed <a | |
| href="http://aether.sonatype.org/using-aether-in-maven-plugins.html">here</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. | |
| </p> | |
| <h2>Legal Issues</h2> | |
| <p>There are no known legal issues.</p> | |
| <h2>Committers</h2> | |
| <p>The following individuals are proposed as initial committers to | |
| the project:</p> | |
| <ul> | |
| <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> | |
| </ul> | |
| <h2>Mentors</h2> | |
| <p>The following Architecture Council members will mentor this | |
| project:</p> | |
| <ul> | |
| <li>Mik Kersten</li> | |
| <li>Wayne Beaton</li> | |
| </ul> | |
| <h2>Interested Parties</h2> | |
| <p>The following individuals, organisations, companies and projects | |
| have expressed interest in this project:</p> | |
| <ul> | |
| <li>Christophe Thiebaud, SAP</li> | |
| <li>Louis Lecaroz, SAP</li> | |
| <li>Andreas Brehmer, SAP</li> | |
| <li>Dain Sundstrom, Proofpoint</li> | |
| </ul> | |
| <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> | |
| <table> | |
| <tr> | |
| <th>Date</th> | |
| <th>Change</th> | |
| </tr> | |
| <tr> | |
| <td>18-August-2011</td> | |
| <td>Added several new committers</td> | |
| </tr> | |
| </table> | |
| </body> | |
| </html> |