Quick Maven Primer for Java Development

I wrote this up for the NetRexx mailing list, but it's a good basics article for anyone wanting to get a quick glance at Maven's operations.  I'm not trying to come up with a better Maven, I'm just giving a quick description.

Maven 102: Advanced Basics

Alternate title:  What you need to do to be a good Maven citizen

Java module layout

Here is the default layout for a java/jar maven module.  You can reconfigure source and output directories, but you may not want to, as I'll discuss in a second. source/input directories:
output directories:

Build Flow

A general flow for Maven in such a project would be to:
  1. compile src/main/java to target/classes
  2. copy src/main/resources to target/classes
  3. compile src/test/java to target/test-classes
  4. copy src/test/resources to target/test-classes
  5. run unit tests, output to target/surefire-reports
  6. build jar, source jar, and test jars, place in target
Again, you can change much of this, but with Maven, the more you fight with it, the more you will have to fight with it.  It kind of snowballs and will cause annoyances down the line, during releases and documentation and site generation and such.


It is not terrible to set up a repository, but the holy grail (for the users, anyway) is to get your libraries uploaded to Maven Central -- this will make the process quite seamless for adding a new compiler to a project because access to Maven Central is basically required for Maven operation.

Custom Language Compilation

Another important task for easy maven integration is compilation.  This will generally require a special maven plugin that can essentially execute  the custom language compiler and conform to something similar to the input and output directories above.  This is not too tricky, especially if there is a java entry point to do the work.


Related to this is a topic of modularity:  how do you break up a project?  How do you resolve circular references across multiple langugaes? For example, you will generally get yourself into trouble if you have:
all in the same module, and are trying to compile them all at once.  Unless you have a single compiler that can process all your source at once, this won't work.  You will be far happier to make multiple modules, use maven to describe the dependencies, and do one language at a time.


  1. Bob Hamilton said,

    October 13, 2010 @ 4:18 pm

    Is there a way to lock a compiler version. Once on a SAP project, the compiler/exec was changed. We never recovered.


  2. Bob Hamilton said,

    October 13, 2010 @ 4:21 pm

    Also, what projects have used/do use Maven?


  3. pforhan said,

    October 13, 2010 @ 9:16 pm

    The compiler is of course set by whatever JDK is installed on the machine running Maven. The plugins used by maven (including the compiler plugin) are prone to be updated in unexpected ways, but yes, you can lock down their version so this doesn’t happen.

    Which projects have used it? A lot of them. It might be easier, however, to instead find out which projects are published as maven artifacts. There are several places to look and search — maven central is one. Basically, all the spring projects, hibernate, apache commons, and much more.

  4. Thomas Schneider said,

    October 14, 2010 @ 5:10 pm

    Excellent 🙂

    Thanks a lot, Patrick!

RSS feed for comments on this post