Maven 3 modules

Question

I am about to start a project. We'll be using Spring MVC, RestEasy, Spring Batch and Spring Security.

Does it make sense to have a module for each of these, e.g.:

Main_Project
   ---pom.xml
   ---Module_Project
         ---pom.xml
   ---Module_MVC
         ---pom.xml
   ---Module_Rest
         ---pom.xml
   ---Module_Batch
         ---pom.xml
   ---Module_Security
         ---pom.xml

Not sure what the best practice is? Or, should I be using one module?

Thanks, adi

score 2 · Answer 1 · answered Apr 02 '13 at 09:42

At first sight it don't make sense.

Since you already know what technologies you need, I guess you already have an idea on how to organize your own code. And this is your own code organization that must drive your modules (not the frameworks you are using).

A general approach that can work (at least it can be a starting point to elaborate an architecture for a traditional web based application):

one module with your model (i.e. database layer, dao, persistent beans,...) - packaging jar
one module with your controllers (i.e. access to database layer, transaction management, business logic, ...) - packaging jar
one module (front layer) with your view files (if any) (jsp, ...) - packaging war
one module (front layer) with your webservices definition (if any) - packaging war

Simon Hellinger · Answer 2 · 2013-04-02T10:04:38.223

Do not order your modules by framework. (Frameworks are dependencies that you add in your modules where you need them, maybe like this:

<project>
    <groupId>com.ourproject</groupId>
    <artifactId>myfeature</artifactId>
    <version>0.0.1-SNAPSHOT</version>
    ...
    <dependencies>
        <dependency>
            <groupId>org.springframework</groupId>
            <artifactId>spring-webmvc</artifactId>
            <version>3.2.2.RELEASE</version>
        </dependency>
    </dependencies>
</project>

There are many different approaches to how to organize your project.

The approach I am currently using organizes software along features. Each feature is then "subdivided" via good old java packages. This way I pack business logic, data access objects and specific resources, all belonging to a specific feature, into one module.

The upside is that you don't have to stretch yourself very hard looking for everything that belongs to the feature, allowing you to introduce or remove features as you wish.

The downside is that you'll have to pack objects that are used by all feature-modules (cross cutting concerns or even common parent-classes) into separate modules and add them as yet another dependendy in each of your modules.

score 1 · Accepted Answer · answered Apr 03 '13 at 12:45

Ignore the frameworks. Split your modules until you can answer "no" to these 2 questions for each module:

"Am I mixing view/controller logic with business logic?"

"Am I mixing features?"

Remember to declare the frameworks in the parent pom.xml so the modules can share the exactly same dependencies.

Maven 3 modules

3 Answers3