John Casey

1. standardization
2. reuse
3. consistency wrt build output
4. dependency management
5. scalability (lower level of additional info/code to add a new step to the build process)

Ashley williams

1. Dependency management
2. Build lifecycle management
3. Large existing repository
4. Eclipse aware (sort of)
5. Well documented (hopefully soon)

Eric Hartmann

1. One directory layout,
2. A single way to define dependencies,
3. Setting up a project is really fast,
4. 99% of my needs are available out of the box,
5. Transitive dependencies ! :-)

Vincent Massol

1. common build structure
2. build best practices enforcement (shared build meme)
3. automated build of application, from source code to pre-production platform => fast time to market with reduced risks
4. works well with distributed teams ;-) Location doesn't matter.

Compared to Ant:

1. Higher level of reusability between builds
2. Faster turn around time to set up a powerful build (once you're used to Maven)
3. Less maintenance
4. Shared build meme. I know how to build any maven project
5. Greater momentum: Ant is now legacy and not moving fast ahead. Maven is forging ahead fast and there's a potential of having lots of high-value tools around Maven (CI, Dashboard project, IDE integration, etc).

Emmanuel Venisse

1. All artifacts are versionned and store in a repository
2. build process is standardized for all projects
3. a lot of goals are available so it isn't necessary to develop some specific build process part contrary to ANT we can reuse existing ANT tasks in build process with antrun plugin
4. it provide quality project information with generated site
5. Easy to learn and use

David Jackman

1. Dependency management
2. Makes the build process much easier at the project level (i.e. don't have to create very much for each project for Maven to build it correctly, and those things you do create are more declarative than functional)
3. Automatic project web sites with consistent information about each project
4. Recommended standards and best practices for project layout and definition

Jesse Mcconnell

1. Promotes modular design of code. by making it simple to manage mulitple projects it allows the design to be laid out into muliple logical parts, weaving these parts together through the use of dependency tracking in pom files.
2. Enforces modular design of code. it is easy to pay lipservice to modular code, but when the code is in seperate compiling projects it is impossible to cross pollinate references between modules of code unless you specifically allow for it in your dependency management... there is no 'I'll just do this now and fix it later' implementations.
3. Dependency Management is clearly declared. with the dependency management mechanism you have to try to screw up your jar versioning...there is none of the classic problem of 'which version of this vendor jar is this?' And setting it up on an existing project rips the top off of the existing mess if it exists when you are forced to make 'unknown' versions in your repository to get things up and running...that or lie to yourself that you know the actual version of ABC.jar.
4. strong typed life cycle there is a strong defined lifecycle that a software system goes thru from the initiation of a build to the end... and the users are allowed to mix and match their system to the lifecycle instead of cobble together their own lifecycle.. this has the additional benefit of allowing people to move from one project to another and speak using the same vocabulary in terms of software building

Henning

1. quick project setup, no complicated build.xml files, just a POM and go
2. all developers in a project use the same jar dependencies due to centralized POM.
3. getting a number of reports and metrics for a project "for free"
4. reduce the size of source distributions, because jars can be pulled from a central location

Roberto Castro

1. Consistency in artifact naming
2. Use of remote repository
3. Web site generation