Maven 2.0 will feel very different to a Maven 1.0 user - and perhaps a little strange. But it is a lot simpler to work with, and closer to how Maven was always meant to be! The key changes from Maven 1.0 are:

• Faster and smaller - The Maven core no longer uses Ant, Jelly or Xerces making it much smaller, has fewer dependencies and is perfect for embedding in other tools.
• Defined build lifecycle - No more prereqs , preGoals and postGoals . The build is a series of well defined phases. This also means that the normal goal names are not used - compile , test and install work for any project type.
• Built-in multiple project handling - Use the same goals on a set of projects, and aggregate the results.
• Improved SNAPSHOT handling - Snapshots are now checked for updates only once per day by default - though can be configured to be once per build, on a particular interval, or never. A command line option can force a check - making it more like updating from an SCM.
• No more properties files - All plugins are now configured from the POM (which is now called pom.xml ).
• No more maven.xml - Plugins are now easier to build and integrate, and are the only way to script your builds. (Note that additions may later be made to the POM to allow simple things that scripting was used for, such as goal aliasing).
• No more Jelly - Plugins are primarily written in Java, though there are providers for other scripting languages. This release includes support for Marmalade, a scripting framework that supports an XML syntax similar to Jelly which can be used to integrate Ant tasks and has a Jelly compatibility layer.
• Improved repository layout - Maven 2.0 supports both the existing layout, and an improved repository layout that has deeper, partitioned structure making it easier to browse.

The answer depends very much on on your circumstances, and in particular whether you are new to Maven or not.

The simple answer is that we hope you'll try Maven 2.0, and use it if it works for you. However, it is a beta release, so you can expect some unexpected bugs. We'd hate for your first experience with Maven 2.0 to be a bad one - so if you are embarking on a big, complicated or mission critical project - we still recommend Maven 1.0.2 as the latest stable release.

If you are already using Maven 1.0 - feel free to try out Maven 2.0, but it may be better to remain on an existing version that is working for you until you need the new features and it covers all of your needs.

If you do use Maven 1.0, and would like to upgrade in the future, you should carefully consider following some of the Best Practices listed. These will make your project a lot easier to migrate in the future.

The following are the known limitations in the current Maven 2.0 release:

• Error handling - there are occasions where Maven 2.0 will drop out with a long stack trace when an error has occurred. If a specific trace is not providing enough information to find out what went wrong, please post the message to JIRA.
• Availability of other plugins - While most of the core Maven 1.x plugins have been converted, there are still some not available, or not with the same level of features or documentation. In addition, several 3rd party plugins may not be available. Maven 2.0 cannot execute Maven 1.0 plugins.

Maven 1.0.2 continues to work, and a 1.1 release is still under way. While significant new features will not be added to the Maven 1.0 core (such as transitive dependencies), bugfixes and support continue and the repository is still available. Features from Maven 2.0 may be included in Maven 1.1 where possible.

An end-of-life for Maven 1.0.2 will be announced when this is decided - but there are currently no plans for this to happen.

Not directly. While Marmalade supports a Jelly compatibility layer - the different POM format and goal architecture would prevent most plugins from working.

We recommend building your Jelly plugins as thin wrappers around Java beans that do not use Maven 1.0 API's, which will allow easy migration to Maven 2.0.

Taken from this post to the Maven User's List :

Everything in m2 is a plugin so for doing any sort of custom work like that you will need to make a plugin. This 1) greatly reduces the complexity within m2 because we only deal with proper plugins. The maven.xml file in m1 was a psuedo plugin essentially and greatly complicated the internals and 2) it promotes the sharing of your work right from the get go. To start with you'll probably write a plugin that is only applicable to your specific requirements, or your team's work, but you'll see people asking for some functionality and you'll go "hey, I have something like that!" and hopefully people who have concrete solutions will generalize their solutions so they can be shared with others. That's what we're trying to encourage.

We estimate that there's a lot of work bound up in project's maven.xml that is not being shared and we'd like to try and change that. We plan to make it dead simple to share plugins and hopefully people can use other project's plugins as a start for a plugin that they may need themselves.