Jason van Zyl on New Aether Library for Interacting with Artifact Repositories

Aether Interview

Jessica Thornsby

JAXenter speaks to Maven founder Jason van Zyl on the new Aether library, and its relationship to Mercury and SAT4J.

Last week, Sonatype announced
, a set of common tools and APIs with the goal of
becoming the standard library for interacting with Maven
repositories. JAXenter spoke to Maven founder Jason van Zyl on what
Aether brings to the world of interoperability, and Aether’s
relationship to Mercury and SAT4J library.

JAXenter: Can you give us an introduction to

Jason van Zyl: 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 of artifacts that 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 use
different ones if you need to. Along with all the rules to resolve
artifacts taking into consideration any transformations,
relocations, and conflict resolution strategies you will 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.

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

Jason van Zyl: It’s more a question of
interoperability of the different 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 a huge problem.
We want to prevent these problems, and we know that people creating
these build tools would prefer to use an as neutral 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 whatever format
they wish for describing their dependency metadata.

JAXenter: 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?

Jason van Zyl: If a project is using the Aether
implementations that Maven itself is using, then they are
guaranteed to have the same behavior Maven does. 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.

JAXenter: What is Aether’s relationship to
Mercury and SAT4J library?

Jason van Zyl: 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.

JAXenter: What is the current status of Aether
Ant Tasks?

Jason van Zyl: 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 its own branch at Github. 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


comments powered by Disqus