How does the maven file structure work?

Question

We are planning on restructuring a complex project with many modules/pieces, what ever you wanna call it. In order to move toward a standard directory structure, we would like to adopt the maven file structure.

So the big question is: Can anybody provide a description of the maven file structure, where we don't have to dig through all the maven speak?

Answer 1

Please see http://maven.apache.org/guides/introduction/introduction-to-the-standard-directory-layout.html

src/main/java      Application/Library sources
src/main/resources   Application/Library resources
src/main/filters    Resource filter files
src/main/assembly    Assembly descriptors
src/main/config      Configuration files
src/main/webapp      Web application sources
src/test/java      Test sources
src/test/resources   Test resources
src/test/filters     Test resource filter files
src/site            Site
LICENSE.txt          Project's license
README.txt        Project's readme

---

BTW, we did that migration on existing projects. It was a really long and hard task to make everything work as intended, but we are finally done and happy with it.

---

UPDATED

When you have many projects, you have the same structure for each project.

Now the real problem starts when you want to group them. We had a hard time reading Maven documentation and best-practices, and deciding what was the appropriate structure for us.

The basic idea would be to group related projects in a common directory (that we call a module), allowing to process the module as a whole without listing them. But if you open the module in an IDE (Eclipse in our case), the projects themselves belong to it, but are not opened as subprojects (that notion doesn't exist in Eclipse).

We ended up with a strict hierarchy, that freed us from many maven problems:

• The actual coding projects (java projects) are always leaf in our directory tree. They are the only ones we open in the IDE. They are of type JAR, or WAR.
• Their parents/modules are always of type POM. They have no java code.

Answer 2

I've been using the same approach as Jens on a number of projects both with Maven 2.2.1 and now with Maven 3.0-alpha-6: POM modules define the module structure of your project tree, JAR/WAR modules are the leaves of the tree. All modules have the same version.

Advantages:

• You can place properties or dependencies on specific levels in the module hierarchy and they will be inherited to all sub-modules.
• You can build related modules simply by going to the appropriate level in the tree and running "mvn install" - Maven will work out the correct build order according.
• Various Maven plugins such as the release plugin rely on this tree structure.
• The latest Maven Eclipse plugin can handle this structure very well and will represent the tree as a flat list. There is an experimental feature in the plugin which ensures that so-called "shadowed" artifacts appear only once which helps when searching for resources in Eclipse.

Disadvantages:

• Extension takes some time. For instance, if you decide that a JAR module requires sub-modules, you will need to convert the existing JAR module into a POM module and then distribute its contents to the newly created JAR sub-modules as POM modules cannot contain any code themselves.
• All the POM modules will appear in Eclipse and can slow down the build somewhat. Hoever, you can close them and Eclipse will source them from the repository instead.