Question

What’s the best way to setup Maven for a project that has a SmartClient architecture? Consider the following packages:

• myproject.core
• myproject.server
• myproject.client

Of course there are several sub-packages in each. Client and Server both use core. I see two main options:

1. Make an uber-POM in myproject to cover all three and have some sort of build parameter to identify what to build.
2. Make a POM in each package above (one for core, another for server and another for client).

Here are the outputs we need to build (at a minimum):

• Standalone.jar: A test application that will launch the server and a client.
• Server.war: A WAR file that can be deployed to Tomcat.
• Client.jar: The SmartClient without any server code.

Is option #1 even possible? If so, is it good practice? From my initial research, option #2 sounds like best practice. However, jumping from POM to POM when all the code is intimately related sounds like extra work and extra clutter we may not need. Should I just stick with option #2?

Answer 1

Maven has a general rule that there should be only a single artifact per project. In other words, option #1 wouldn’t allow you to produce a server.war, a client.jar, etc without fighting against maven. This would be a big mess and you wouldn’t be able to take advantage of maven plugins. No, really, you don’t want this. So just go for option #2, with a structure like (omitting the src directory):

.
|-- core
|   `-- pom.xml
|-- server
|   `-- pom.xml
|-- client
|   `-- pom.xml
`-- pom.xml

Regarding your concern about jumping from POM to POM, well, just import all modules into your IDE and you won’t really notice it. This just works pretty well for lots of people.

UPDATE (to cover questions from the OP in comments):

Fighting against Maven doesn’t sound fun.

No, and you will loose 🙂

What is in the pom.xml at the root level?

This is a parent POM used for Project Aggregation. Quoting the Introduction to the POM document:

Project Aggregation is similar to
Project Inheritance. But instead of
specifying the parent POM from the
module, it specifies the modules from
the parent POM. By doing so, the
parent project now knows its modules,
and if a Maven command is invoked
against the parent project, that Maven
command will then be executed to the
parent’s modules as well. To do
Project Aggregation, you must do the
following:

• Change the parent POMs packaging to the value “pom” .
• Specify in the parent POM the directories of its modules (children
  POMs)

Project aggregation and project inheritance are often used together. Refer to the mentioned document for more details.

By “single artifact per project” do you mean that there should be a separate POM for Standalone.jar, Server.war, and Client.jar (three total POMs)?

Yes, this is what I mean, one project generates one artifact (there are some exceptions but this is true 99% of the time). This is a maven best practice that you should (must?) follow.

What if I also want a Server.jar, a simple server based with Grizzly included? Wouldn’t server need two POM’s?

I think that the maven way to handle this would be to use assemblies and there is no unique answer to your question (this might be one of the exception to the rule mentioned above). But this won’t prevent you from starting.

Also, how would one kick off a build that would result in all three artifacts getting produced?

Launch your maven command from an aggregating project as we saw (aka “multi-modules build”).