Project folder structure is an important part to understand Maven. It’s the practical part of Convention over Configuration (CoC) previously explained. After the project creation, all Maven projects will follow this folder structure. So, if you understand this part, you will master any Maven project.
Basic Folder Structure
To jumpstart your Maven utilization, let’s cover the most common folders. On some advanced projects, you may find a module folder organization but we can talk about it later.
On root folder, with the POM file, there are just a few archives.
- LICENSE and README are common textual documents on Open Source projects.
- The most important is the src folder, where you store all of your code.
- Finally the target folder, the place where Maven generates all compiled files, tests and the final package. Never commit it to your source control.
Inside of src folder, there is a well-defined structure to organize your code. The most commons are main and test folders.
Main Folder
src/main/java: As the name already says, the place to store your Java application code.src/main/resources: Used resources like XML configuration files, SQL files, META-INF folder.src/main/webapp: If it’s a web project, it’s the place to store WEB-INF folder with JSPs and resources like CSS, images, JavaScript.
Test Folder
src/test/java: The same way as your Java code. But with this approach, it’s possible to define tests using the same packages of your main code. This is exclusively focused on Unit Tests.src/main/resources: Used resources to configure tests like specific XML files.
Overview
Once we understand the basic folder convention, let’s take a closer look at a common non-Maven project converted to a Maven project. To make this explanation easier, I got part of the project spring-mvc-webapp, a Spring Archetype, as a base.
This is a common Java Web project generated by an IDE. This is how I used to create my Java projects.
cyborg-mvc
├── CyborgWeb
│ ├── WEB-INF
│ │ ├── views
│ │ │ └── index.jsp
│ │ └── web.xml
│ ├── css
│ │ └── screen.css
│ ├── images
│ │ └── cyborg.png
│ └── js
├── resources
│ └── import.sql
└── src
├── resources
│ └── persistence.xml
└── tech
└── cyborgdeveloper
├── controller
│ ├── MemberController.java
│ └── MemberRestController.java
├── data
│ ├── MemberDao.java
│ └── MemberDaoImpl.java
└── model
└── Member.java
This is how my project should be according to Maven conventions.
cyborg-mvc-maven
├── README.md
├── pom.xml
└── src
├── main
│ ├── java
│ │ └── tech
│ │ └── cyborgdeveloper
│ │ ├── controller
│ │ │ ├── MemberController.java
│ │ │ └── MemberRestController.java
│ │ ├── data
│ │ │ ├── MemberDao.java
│ │ │ └── MemberDaoImpl.java
│ │ └── model
│ │ └── Member.java
│ ├── resources
│ │ ├── META-INF
│ │ │ ├── persistence.xml
│ │ │ └── spring
│ │ │ └── applicationContext.xml
│ │ └── import.sql
│ └── webapp
│ ├── WEB-INF
│ │ ├── views
│ │ │ └── index.jsp
│ │ └── web.xml
│ └── resources
│ ├── css
│ │ └── screen.css
│ ├── images
│ │ └── cyborg.png
│ └── js
└── test
├── java
│ └── tech
│ └── cyborgdeveloper
│ └── test
│ └── MemberDaoTest.java
└── resources
├── META-INF
│ └── test-persistence.xml
├── import.sql
└── test-context.xml
There are some main differences:
- Java code location is now at src/main/java.
- Resources at src/main/resouces.
- Web content has a default folder at src/main/webapp.
- Unit Tests now has a specific organization under src/test folder.
src/tech/cyborgdeveloper/* -> src/main/java/tech/cyborgdeveloper/* src/resources/* -> src/main/resources/* CyborgWeb/* -> src/main/webapp/* ? -> src/test/*
This will be the beginning of any journey to converting a project to Maven. Once it’s done, the team can reap the benefits of a pattern project structure. Now any new employee or a teammate that joined the project will be able to do a fast scan and understand how the project works.
Many of these challenges you’ll only need to face once. They are base configurations that don’t change much. The next challenge is to deal with dependencies.
Share your victories or problems during this journey through the comments. What is your biggest challenge to automate your build process?
Let’s automate!
