Apache Maven 3.0 has landed, but it’s really just the beginning. The work that Sonatype has done to bring Maven 3.0 to fruition is substantial. It’s been hard, it’s taken a lot of Sonatype’s time and resources, but we’re glad we did the work and we see this as a new beginning for Maven. We will, of course, keep working on Maven but with the release of Maven 3.0 Sonatype will, at least for a little while, turn an eye to Maven’s Eclipse-focused cousins, the Maven Shell, Polyglot Maven, and Hudson.

We have work to do on Tycho to get it fully setup for the parallel IP process at Eclipse, we will soon start a very intensive set of iterations to bring the M2Eclipse core to a 1.0 state, and we have committed within Sonatype to move M2Eclipse to the Eclipse Foundation. The M2Eclipse project at Eclipse has been in suspended animation for a while but we plan to work toward getting M2Eclipse into the release train and have Indigo be the first Eclipse distribution to ship with Maven capabilities. Tycho and M2Eclipse will also be a lot of work, but I think Sonatype has demonstrated that we’re committed to making these projects work and can deliver as we’ve shown with Maven 3.0.

There will be a release fairly soon of the Maven Shell, I will be starting a new phase of work on Polyglot Maven, and I’ll also be talking about concretely what Sonatype plans to do around Hudson — and what we’ve already done. Once we get a few more of the projects we’re working on to a healthy state we will begin the dialog with the community about what features users are looking for in future versions of Maven and related tools.

The Maven community owes a special thanks to Benjamin Bentmann, who has worked consistently and persistently for a long time on Maven 3.0. He has been amazingly responsive in applying fixes for reported issues, and has set the bar very high for the quality of a open source project. We have an enormous number of integration tests and without a doubt, Benjamin really has made this the best version of Maven we’ve ever had. I’d also like to thank Igor Fedorenko who is responsible for Tycho, along with all the changes he made to Maven core to allow its dynamic adaptation, as well as putting in place the performance framework for Maven 3.0. And Maven users can also thank Oliver Lamy for making sure the Maven Site Plugin is compatible with Maven 3.0.

You can download Maven 3.0 now!

http://www.apache.org/dyn/closer.cgi/maven/binaries/apache-maven-3.0-bin.zip

http://www.apache.org/dyn/closer.cgi/maven/binaries/apache-maven-3.0-bin.tar.gz

Enjoy!

We are very close to Maven 3.0! In preparation for the release we are entering the RC phase Sonatype is seeking the Maven user community’s help to discover regressions since Maven 2.x so that we can make the necessary provisions to correct any problems and push Maven 3.0 final out on schedule.

We know as the RCs are released more people will be trying Maven 3.x and feedback is critical. We obviously cannot fix your problem if you do not report the problem. Sonatype has two full-time people working on fielding the found issues so this is your chance to make sure Maven 3.0 final works for your projects. Sonatype has made a great deal of effort putting in place unit tests, integration tests, and performance tests for the core and the core plugins, so we’re ready for the feedback and will correct anything we find quickly.

Anyone interested in taking a preview of the upcoming release for a test drive can get source and binary bundles from this URL:

https://repository.apache.org/content/repositories/maven-030/org/apache/maven/apache-maven/3.0-RC1/

Note that this is a staged release and we will keep re-staging while we find serious regressions, but we want to get users into this cycle of testing the RCs as soon as possible. Once we get past anything nasty we will release the final RC1.

Before reporting any issues found during testing, please be sure to have a close look at the compatibility notes for Maven 3.x:

https://cwiki.apache.org/confluence/display/MAVEN/Maven+3.x+Compatibility+Notes

If you encounter unexpected build issues, please fill a report in JIRA that provides sufficient information to reproduce and analyze the issue:

http://jira.codehaus.org/browse/MNG

The fixes contained in this release candidate since the 3.0-beta-3 release can also be seen in JIRA:

http://jira.codehaus.org/secure/ReleaseNote.jspa?atl_token=PRIR5ueW-i&version=13142&styleName=Text&projectId=10500&Create=Create

It’s still possible to make our intended Maven 3.0 final release on October 1st, but we need your help!

Thanks!

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.

(more…)

Introducing Aether

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.

Aether Resources

If you are interested in Aether here are the goods:

• Aether Sources @ Github
• Aether Issue Tracking @ Sonatype
• Aether Wiki @ Sonatype
• Mailing lists:
  • Aether Users @ sonatype.org
  • Aether Developers @ sonatype.org
  • Aether SCM @ sonatype.org

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.

(more…)