JAXenter speaks to Maven founder Jason van Zyl on the new Aether library, and its relationship to Mercury and SAT4J.
Last week, Sonatype announced Aether, 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 Aether?
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.