Why Maven? What Are the Benefits

Maven: advantages of dependency management

Using a per-project lib seems like a simple solution and it is. But eventually you will run into problems:

How do you remember where you got foo.jar from?
Are you sure it was a legit source that no hacker tampered with?
Which version is foo.jar exactly? Is it the original version or something that you patched?
You want JavaDoc/sources with that?
foo.jar needs a.jar which needs y.jar which needs z.jar needs ... You really want to download all that and manage it individually?
You start a second project. Now you have two lib folders. Do you copy the jars or do you reference them from the first project?
Your second project needs a different version of one JAR. How do you handle this?
Imagine you want to upgrade foo.jar to the next version. With Maven, this is a one-minute task. With a lib folder, it means: Searching the web, downloading the JAR, putting it in the right place, possible renaming it, deleting the old version, adding the new version, committing the change, cursing, doing the same for all dependencies, ...
You want to share your project with someone else. They might not want your versions of the JARs - Maven has a simple and efficient mechanism to override dependencies.
Eventually, your legal department will come to ask you to guarantee that your project is clean of incompatible licenses. Maven can give you a report of all licenses of all your dependencies.

Maven Multi Module benefits over simple dependency

Here's a real life case.

I have a multi-module project (and to your rant... I haven't seen any complications with it.) The end result is a webapp but I have different modules for api, impl, and webapp.

12 months after creating the project I find that I have to integrate with Amazon S3 using a stand-alone process run from a jar. I add a new module which depends on api/impl and write my code for the integration in the new module. I use the assembly plugin (or something like it) to create a runnable jar and now I have a war I can deploy in tomcat and a process I can deploy on another server. I have no web classes in my S3 integration process and I have no Amazon dependencies in my webapp but I can share all the stuff in api and impl.

3 months after that we decide to create a REST webapp. We want to do it as a separate app instead of just new URL mappings in the existing webapp. Simple. One more module, another webapp created as the result of the maven build with no special tinkering. Business logic is shared easily between webapp and rest-webapp and I can deploy them as needed.

Why do I need Maven if I use Eclipse?

Maven is a build tool (build manager, in fact), similar to ANT. The main job of any build tool is configure the project, compile using required projects and do the final packaging. A build script in your project gives a blue-print of project's deliverable structure. This frees you from any configurable dependencies on specific IDE like Eclipse. All you need to know is the standard command to perform the build and you can build your code almost anywhere.

Now, back to your question, why wouldn't do it in Eclipse?

For a simple project and small team Maven is an overkill. You can easily communicate the configuration, IDE to use, and instruct any special steps to be taken. In big projects, however, there exits lots of loosely coupled dependencies. To start with, there will be different settings for developer machine build, test build and production build. There are requirements to run automated test, integration tests, store the build package (artifact) to a commonly accessible repository, update versions of various modules.

Obviously, if all the steps mentioned above is done manually there are chances of missing a step. Moreover, the manual process is time consuming.

Ideally, you should prefer a tool which fits the best for you. If you think that you're able to achieve what you required without Maven, it makes sense to not to use Maven/build-tool just because everyone uses it.

It is suggested to study automated deployment, this will give you bigger picture on what all the stuffs that you can do with build tools. And if you do not feel that it adds any value to your current process, you probably don't need Maven or any other build tool right now.

Is there any benefit in using Maven Multimodule when working in a small application?

Splitting your application makes sense for the following:

When a certain part of the project needs to have new functionality or bug fixes, you can simply focus on that module and run just the tests for it. Compiling a fraction of all the code and running just the related tests speeds up your work.
You can re-use the code from the modules across different projects. Let's assume your project contains some well-written generic-enough code for mail sending. If you later have another project that need mail sending functionality, you can simply re-use your existing module or build upon it (in another module by adding it as a dependency).
Easier maintainability on the long run. Maybe now it seems like a small project. In a few months things might look different and then you'll need to do more refactoring to split things into logical units (modules).
Conceptual clarity (as added by Adriaan Koster).

Concerning the WAR: You can have an assembly module which puts things together and produces a final WAR file from all the related modules.

Initially, this may seem as more work, but in the long-run, modularized projects are easier to work with and to maintain. Most sane developers would prefer this approach.

What does Maven do, in theory and in practice? When is it worth to use it?

What it does

Maven is a "build management tool", it is for defining how your .java files get compiled to .class, packaged into .jar (or .war or .ear) files, (pre/post)processed with tools, managing your CLASSPATH, and all others sorts of tasks that are required to build your project. It is similar to Apache Ant or Gradle or Makefiles in C/C++, but it attempts to be completely self-contained in it that you shouldn't need any additional tools or scripts by incorporating other common tasks like downloading & installing necessary libraries etc.

It is also designed around the "build portability" theme, so that you don't get issues as having the same code with the same buildscript working on one computer but not on another one (this is a known issue, we have VMs of Windows 98 machines since we couldn't get some of our Delphi applications compiling anywhere else). Because of this, it is also the best way to work on a project between people who use different IDEs since IDE-generated Ant scripts are hard to import into other IDEs, but all IDEs nowadays understand and support Maven (IntelliJ, Eclipse, and NetBeans). Even if you don't end up liking Maven, it ends up being the point of reference for all other modern builds tools.

Why you should use it

There are three things about Maven that are very nice.

Maven will (after you declare which ones you are using) download all the libraries that you use and the libraries that they use for you automatically. This is very nice, and makes dealing with lots of libraries ridiculously easy. This lets you avoid "dependency hell". It is similar to Apache Ant's Ivy.
It uses "Convention over Configuration" so that by default you don't need to define the tasks you want to do. You don't need to write a "compile", "test", "package", or "clean" step like you would have to do in Ant or a Makefile. Just put the files in the places in which Maven expects them and it should work off of the bat.
Maven also has lots of nice plug-ins that you can install that will handle many routine tasks from generating Java classes from an XSD schema using JAXB to measuring test coverage with Cobertura. Just add them to your pom.xml and they will integrate with everything else you want to do.

The initial learning curve is steep, but (nearly) every professional Java developer uses Maven or wishes they did. You should use Maven on every project although don't be surprised if it takes you a while to get used to it and that sometimes you wish you could just do things manually, since learning something new sometimes hurts. However, once you truly get used to Maven you will find that build management takes almost no time at all.

How to Start

The best place to start is "Maven in 5 Minutes". It will get you start with a project ready for you to code in with all the necessary files and folders set-up (yes, I recommend using the quickstart archetype, at least at first).

After you get started you'll want a better understanding over how the tool is intended to be used. For that "Better Builds with Maven" is the most thorough place to understand the guts of how it works, however, "Maven: The Complete Reference" is more up-to-date. Read the first one for understanding, but then use the second one for reference.

What are the benefits of including a pom as dependency?

AFAIK, including a pom as a dependency will only affect dependencies. If you want reuse other things you have to specify it as parent POM.

Note: I recommend to manage your repositories in a Maven Repository Manager such as Nexus, not in the POMs.

http://www.sonatype.com/books/nexus-book/reference/maven-sect-single-group.html