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!
Recently, I was asked to do an interview for EclipseMagazine about the future of Maven and release of Maven 3.0. JAXenter published part one and two of the interview over two weeks. Below is the full interview, which covers everything from changes Maven 2 users can expect when migrating to Maven 3, Nexus repository manager, the Maven Shell, Polyglot Maven, and more.
With the switch from Maven 1.x to 2, developers had to manage some fundamental changes. What challenges can users expect when migrating from Maven 2 to Maven 3?
We are planning that, in most cases, Maven 3.0 will be a drop-in replacement for Maven 2.x. We have gone to great lengths to ensure backward compatibility while reimplementing a good portion of Maven’s internals. From the command-line perspective we are trying to be fully compatible. Maven 3.0 will not allow duplicate dependency or plugin declarations, so those problems would need to be fixed, but aside from that no changes to your POMs will be required. In all other regards we have created backward compatibility layers to protect users from the many internal API changes that we have made. I really hope that the Maven community can move forward to Maven 3.0 without grief, and use the new features as it is convenient for them.
Is there anything users should keep in mind when creating a new project, to be prepared for Maven 3?
It honestly shouldn’t be any different from Maven 2.0. That’s the intended goal. So much has changed under the covers that we didn’t want to change the POM format. The primary goal is a path forward for all Maven users, efficient embedding, increased performance, synchronizing the Maven 3.0 code base with m2eclipse, and adding extension points for tools like Tycho, Polyglot Maven, and the Maven Shell.
Sonatype is a gold sponsor at EclipseCon so we have a room for the day to some extra presentations and demos. If you’re at EclipseCon and you’re interested in Maven, M2Eclipse, Nexus, or Tycho then please come to the Camino room on the second floor!
10:00am: Developing with Maven 3.0 and M2Eclipse 1.0
A discussion of the changes that have been made in Maven 3.0 to better support interoperation with Eclipse, the roadmap toward the 1.0 release, and an overview of the current features. We will also be talking about Maven Studio for Eclipse, Sonatype’s new Maven-focused Eclipse IDE.
11:00am: Managing p2 Repositories and Repository Interoperability with Nexus Professional
A discussion of how Sonatype is trying to simplify the management of P2 repositories with Nexus.
1:00pm: Tycho Workshop & Demo Extravaganza!
Anyone who is interested in an alternative to PDEBuild, Buckminster, or Athena. Tycho is a set of Maven 3.0 plugins which make up the next generation headless build solution for Eclipse-based products and OSGi bundles. This will hands on workshop where we will provide demonstrations and help you convert your build to Tycho!
See you there!
Parleys.com has just published my “Maven 3: Reloaded” presentation from Devoxx ’09. In this presentation, I put our current focus on Maven 3 in context and talk about some of the upcoming technologies like Polyglot Maven and Maven Shell. In this video you’ll see me demonstrate POM translation from XML to Groovy, discuss the ways in which Maven 3 changes allow m2eclipse to embed Maven, and some of the work we’ve done in Tycho to provide a path for OSGi developers.
You watch this embedded video, or watch the presentation over on the Parleys.com site.
Note: To switch between the slides and the video of me talking, click on the smaller video in the upper right-hand of this video embed.
There are numerous problems with the Maven repositories on Java.net, and individual projects are being penalized for poor development infrastructure at Java.net. We hear no end of complaints about the poor quality of Maven Repositories at Java.net: mixing of Maven 1 and Maven 2 repositories, the mixing of releases and snapshots, lack of javadocs, sources, signatures, bad project metadata, and general inability of Java.net to provide any coherent means of delivering valid repository content to the Maven community.
This is not a problem with any particular project at Java.net, it’s the infrastructure provided by Java.net that isn’t up to par. You need to provide a decent Maven repository infrastructure for projects to deploy their content to, and you need to provide instructions about best practices on how accomplish this properly. Java.net has done neither, so I figured instead of continuing to complain –and continuing to field the complaints of Maven users– I’m going to do something about it.
On March 5th, 2010 Juven Xu and Marvin Froeder from Sonatype will start servicing any and all requests from Java.net projects to migrate their Maven Repository infrastructure over to our hosted Nexus OSS instance. We will, of course, continue to service requests after March 5th, but March 5th will be set aside to specifically help Java.net projects get switched over and tested.
We generally ask that projects interested in our OSS hosting service familiarize themselves with our guide for OSS Repository Hosting. If you follow the guide and make your request we will process the requests on a first come, first serve basis on March 5th. We’ve helped close to 100 projects now and we’d love to help the projects at Java.net!