When developing plugins for Maven 3.0 plugin developers that need to perform dependency resolution have a choice: they can continue to use the Maven 2.x API, or they can use the new Maven 3 API which makes use of Aether. In this post, I’m going to walk through some of the API features that are now available to plugin developers in Aether.
If your plugin needs to be compatible with Maven 2.x, take a look at the sources of Maven Dependency Plugin. This example provides a sophisticated example of using the Maven 2.x dependency resolution API. But if legacy Maven support is of no concern to you, read on and see how the Maven 3.x API handles the job.
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.
Aether (pronounced ē’thər, as in flying though the ether) aims to be the standard library for interacting with Maven repositories. Without question, the most important aspect of the Maven ecosystem is interoperability at the repository level. There are many emerging options in the build space for JVM-based languages, but the one thing they all have in common is their interaction with Maven repositories. It’s clear that Maven repositories play a critical role within JVM-based development infrastructures and Aether will provide the necessary interoperability, through a common set of tools and APIs, that’s critical for happy users in the ecosystem.
Aether & Maven 3.x
Benjamin Bentmann, Sonatype’s lead on Maven 3.x, has fully integrated Aether back into Maven 3.x. Though Aether is an extraction from Maven, Aether is not Maven specific. That said Maven 3.x and Maven repositories are our first priorities. The upshot is that if you embed Aether, you will be embedding the same library that Maven 3.x uses when it interacts with a Maven repository. If compatibility with Maven repositories is important for your project then it’s not going to get any better than Aether.
Aether & Mercury
Mercury was our first attempt at extracting a Repository API from Maven and that didn’t work. We bit off more then we could chew, and so our first attempt was a learning experience. We attempted to integrate the excellent SAT4J library but didn’t have enough experience to pull that off. In addition there may be features of SAT4J Maven requires that are not present yet. As such, we felt it better to attempt something less ambitious, yet functional, and invest in research for future improvements.
Aether, p2 & SAT4J
As part that investment, we will be collaborating in sponsored research with Daniel Le Berre, who is the author of SAT4J. Daniel is a tenured professor at University of Lens, and researcher at Centre de Recherche en Informatique de Lens and is affiliated with Centre National de la Recherche Scientifique. His work will not only help us with p2, but also with many things we want to accomplish in Maven. We see a lot of overlap in the work Sonatype is doing on Maven and p2 and ultimately we really see there being one artifact resolving framework.
Aether & Ant
Rest assured there will be excellent Aether Ant Tasks. Making sure that Aether works flawlessly inside Maven 3.x is our first priority, but we are committed to making a set of excellent Aether Ant Tasks. If you’re interested in Aether Ant Tasks you can follow the progress here.
If you are interested in Aether here are the goods:
P.S. Thanks to Pierre-A Grégoire for the name Aether!