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.
It’s not too late to register for the Sonatype Maven Meetup taking place on April 7, 2010 ahead of Emerging Technologies for the Enterprise in Philadelphia. Meet with Maven aficionados, sit in on presentations about Maven 3, Tycho, OSGi, Peaberry, and much more.
Choose from a dozen different sessions throughout the day, presented by the developers who are building the Maven software you’ll be using in the future. Join us for an interactive BoF session at the end of the day, followed by a reception.
Special Promotion — Bring a Friend for Free
Register one attendee at the $190 standard registration rate, and have a friend join you at no charge.
Visit www.sonatype.com/meetup2010 to register or for more information. When you register, add “+1″ after your name to receive the special promotion pricing for you and a friend.
Seating is limited
Maven Shell is a CLI interface for Maven that enables faster turn-around, and a more intelligent interaction with repositories and projects. Using Maven Shell, you will be able to speed up your builds because project information and Maven plugins are loaded into a single, always-ready JVM instance which can execute a Maven build.
The following IT blog post takes you through the basics of Maven Shell, and gives a quick lesson on what you can expect from Maven Shell 0.10.
Sonatype has released a nifty utility called Maven Shell that allows developers to execute maven goals/phases in a pre-loaded shell environment, significantly reducing the build time. It does this by loading up a JVM, Maven, and any loaded plugin once and leverages that existing load for each subsequent build. I downloaded the .10 binary and played around with it with a very simple multi-module project.
Read the full article here. And to get started, download the latest release of Maven Shell 0.10.
This mackaz.de blog post shows you how to build an application using Maven, with both Java and Scala source files. Your project will be set up so that the Java-classes can access Scala-classes and vice versa.
The project automatically uses the latest Scala 2.8-Snapshot until it’s released (Maven will look for the latest version of the Scala language each time you build it). We will setup the project to use cross-compiling, so the java-classes can access scala-classes and the other way around.
To read the full tutorial, click here.
We recently started raising the minimum criteria for artifacts coming into Central:
- Blind rsync transfers of random repositories are no longer being added and will be phased out over time
- All artifacts must be properly signed with GPG signatures that are publicly verifiable
- sources and javadocs must be included
- scm urls must be included
- No external repository definitions
That last one seems to cause the most commotion for users that depend on artifacts not currently in Central and I wanted to take this opportunity to show why this is being done.
The urls you see below are listed as RELEASE repositories found in the poms of a prominent repo we’re attempting to clean for syncing to Central. In the list below you will find some interesting bits:
- file based urls
- urls with private ip subnets
- snapshot repositories (remember this is a list of the RELEASE repos only according to the poms
- Links to websites (like [http://maven.apache.org]) or wikis
- Many sites that no longer exist
- Repositories that are actually mirrors of Central (Ibiblio)
- Repositories who’s contents are already in Central (codehaus)
Of the few repositories that actually do still work, many of them have what I would call “garbage” in them. I’ll define garbage here as things that didn’t originate from this project and are either hacked/patched versions and/or duplicates of artifacts that are found somewhere else.
When you start blindly using these repos, best case you could get artifacts who’s provenance is suspect and your builds are slowed down because Maven is sent off on a wild goose chase. Worst case, you still have to find these repos by hand and override the bad urls.
In the list below, I think my favorite is the dynamic search of a Fisheye repository at Atlassian.com. I’m sure they love having thousands of builds doing automated searches of their Fisheye service looking for every artifact in a build.
When we sync these poms to Central, it is highly likely we will simply ditch all of these references. We don’t take changing poms likely, but in this case it is clearly the lesser of two evils. Having the ability to leverage artifacts in some other repo is a nice fix in the moment, but once you release your project this way, you forever become a slave to that project maintaining the repo.
In order to improve the experience for everyone, we are working to block this from happening in Central. We have several efforts underway to help minimize this impact, and that primarily includes making it easier to get your artifacts and third party artifacts into Central. Stay tuned for more exciting announcements on this topic.