This is the home page for the Maven users space. Where users can contribute documentation for others users and for incorporation into the main site. Any users with outside documentation should share it with others here. This is our sandbox and it's only as good as we make it.

Table of Contents

This wiki space is not for final documentation, but a workspace for creating it. If you think a document can be contributed back to the main site, please record that in JIRA. For discussions, ideas and design documents related to Maven, see the Maven space.

Introduction\

If you're a java software developer that's worked in any type of team situation, you know that the process is important to developing a quality product. Also, you know, that rote methods maintain consistency and standardization among developers. Apache ANT does that for some of us very well. Maven kicked it up a notch in several areas. Maven took some of that classpath and jar dependency frustration out of the hands of the day-to-day developer. Most will agree with me that project structure, dependencies, J2EE packaging, etc. is very difficult. When things are not structured correctly, applications don't work. Jars could be in the wrong place, jars could be the wrong version, an XML might be missing a descriptor, and a host of other project infrastructure issues can bring a project to stop. When this happens it's sometimes difficult to determine where things are wrong. And, most developers aren't up on all their J2EE archive types. Nor do they focus on the trivia of J2EE descriptors. Developers Maven is an excellent tool that solves most of these problems.

While the stereotypical project manager might disagree with me, Maven meets the project manager and the development staff somewhere in the middle. Apache's ANT is a powerful tool, but there's no standardization in targets. In fact, it may be too customizable. Maven did right by holding to a distinct set of build lifecycle goals. If you're the do-it-yourself type, you can create your own plugins to extend the functionality of Maven. Project managers want control and Maven injects this technical control into the build process. Maven assures everyone that the build and deploy process is done the same everytime. Musician's practice scale repetition for this very reason. Rote processes that work are very effective because their commonality and effectiveness save time and assure quality.

The documentation listed in the table of contents is meant to be a place to begin to learn how to use Maven. Many development shops and software groups may be using Maven1 now. If you are, please take a look at Maven2. For anything to become a standard, it must be proven to be the standard by our use. Let's make Maven(2) the standard in our build process. Let's go write quality software and let Maven do our heavy lifting.

Help Wanted!

Here are some ways you can contribute:

Write or adjust the docs in this wiki space

Add placeholder pages for docs you'd like, with an outline about what you think is needed (preferably file in JIRA and link to the page too)