Aether questions answered for JAX

JAX asked me some questions about Aether so I'm providing the the English version of the answers here for the community. The German version should show up on the JAX site shortly.

## Can you give us an introduction to Aether? ##

Aether is a library for interacting with artifact repositories. This involves the specification of local repository formats, remote repository formats, workspaces, transports, and artifact resolution. People are generally familiar with repositories whether they be local or remote. Workspaces are additional sources where artifacts can be resolved from. Workspaces can be used in IDEs to provide resolution of projects you are working on, in shells like the Maven Shell or Roo, or any other long-lived process where a developer needs to resolve against in-development projects. I think people are familiar with various transports but HTTP is by far the dominant transport used with artifact repositories, but Aether lets you define additional ones if you need to. Along with all the rules to resolve artifacts taking into consideration any transformations, relocations, and conflict resolution strategies you might need to employ. We also plan to allow Aether to define version schemes, but the first work was just started on this by Alin Dreghiciu.

It is very important to note that Aether has no dependencies on Maven. When I said Aether is a library for interacting with artifact repositories, I didn't mean Maven artifact repositories. Aether is a general purpose library for interacting with artifact repositories. If you wanted to specify your dependency metadata in a properties files Aether will let you do that. If you want to store your artifacts in a database Aether will let you do that. But, of course, we needed Aether to work for Maven so we created an implementation of what we call an ArtifactDescriptorReader to process Maven POMs. That implementation lives in the Maven codebase and that's how we make Aether work for Maven.

## Why is interoperability at the repository level, so important for Maven projects? ##

It's more a question of interoperability between tools that interact with Maven repositories. Maven projects interoperate because they all use Maven. What we want to ensure is that projects building with SBT, Leinigen, Gradle, Buildr, Ant, or a homegrown system interoperate reliably with Maven repositories. Maven repositories are the defacto standard storehouses of JVM components. If a project that builds with Gradle can't interoperate with a project built with Maven on the same machine because the local repository format that Ivy produces is not compatible then we see that as highly problematic. We want to prevent these problems, and we know that people creating these build tools would prefer to use as neutral a library as possible. Of course, to interoperate with Maven repositories integrators will require the ArtifactDescriptorReader to process POMs from remote repositories but they can create their own format for describing their dependency metadata.

## At the project announcement, it is stated that “if compatibility with Maven repositories is important for your project then it’s not going to get any better than Aether.” Why is this? ##

If a project is using the Aether implementations that Maven itself is using then they are guaranteed to have the same behavior Maven does for resolving artifacts. If SBT is using the exact same code as Maven to read and process POMs, and the same local repository implementation then the level of interoperability is pretty much guaranteed. All the various tools may want to express their dependencies in their own particular way, but it would be bad if they interpreted POMs differently, did conflict resolution differently, or deployed artifact metadata incorrectly. These types of problems just wreak havoc for the average user trying to use artifacts from Maven repositories.

## What is Aether's relationship to Mercury and SAT4J library? ##

Mercury was our previous attempt at a library like Aether. We learned many things from Mercury, but it was a failed attempt because we tried to do too much at once. We tried to completely separate the resolution code from Maven, and introduce SAT4J at the same time. This proved to be a fatal mistake, but we have learned from our mistakes. Since Mercury we've brought Pascal Rapicault, the lead of the Eclipse p2 project, to the Sonatype team. Pascal is very familiar with SAT4J, but more importantly Pascal has a very good working relationship with Daniel Le Berre, who is the author of the SAT4J library. In talking with Pascal about our goals for Aether we concluded that we should design Aether to eventually allow a collaboration with SAT4J but not use it in our first pass. Our primary goal was to create a general purpose library that could be used in any tool including Maven. It's also going to take more research and experimentation to understand exactly how we will integrate SAT4J. It's not a question of if we will integrate SAT4J, it's a question of when.

## What is the current status of Aether Ant Tasks? ##

The Aether Ant Tasks are functional. They currently do the basic resolving, installing, and deploying. But there are some clarifications that we want to make in the syntax before we make an official release. The Aether Ant Tasks can be found in their [own branch at Github][1]. For those interested in discussing what the syntax should look like for the Aether Ant Tasks we encourage you to subscribe to the [Aether development list][2]. One short term goal with the Aether Ant Tasks is to provide a complete Ant-based solution for [submitting artifacts to Maven Central][3].

We also intend to demonstrate how to make submissions to Maven Central programmatically using Aether so integrators can participate as freely in the exchange of JVM artifacts as Maven projects do now.

[1]: http://github.com/sonatype/sonatype-aether/tree/ant/aether-ant-tasks/
[2]: mailto:aether-dev-subscribe@sonatype.org
[3]: https://docs.sonatype.org/display/repository/sonatype+oss+maven+repository+usage+guide