So you have a platform you are trying to make – most of it written using Java, maybe a little nodejs, zeromq or some other such goodies but you want to manage your java resources using as much out-of-the-box engineering to reduce overall boilerplate and headaches that come with a compiled language. You decide to go with maven because, well it’s better than JAR hell, and has more cool kids using it (github, etc). Tooling support is more than decent and you’ve got support by most if not all Apache projects for dependencies.
- The system should be able to build the entire project and all dependencies in one go.
- The system should be able to load the entire solution into an IDE (Eclipse)
- The system should follow DRY and KISS – things should be in one place, and things should only do one thing and do it well
- The system should be able to create a pit of success (proper documentation, unit tests, code coverage, reports, site creation, etc)
The example solution structure below is the same as that is used by Hibernate and some top level Apache projects.
./your_solution ./pom.xml (solution level pom, glue for which modules are part of solution) ./modules (all modules for the solution) ./core (common shared lib, usually domain objects, etc) ./src ./pom.xml (standard maven module pom with ref to parent) ./api (api for exposing jersey, jax-ws, jax-b services) ./src ./pom.xml (standard maven module pom with ref to parent) ./parent (parent pom container) ./pom.xml (standard parent pom)
The solution POM simply exists to setup the list of modules. Used primarily by build tools as well as IDE's this POM contains a listing of all modules that make up this solution. This combined with default properties and/or build profiles, default group id, packaging, etc.
Contains all common settings, build plugins, common libraries, frameworks, test tools, etc. Normally this includes all standards like custom repositories, which java version to target. Also common build dependencies such as junit, logging frameworks.
Finally the parent pom usually specifies the site generators, javadoc options, and team members, etc for site generation.
Specific to each logical component in the overall app/solution architecture. Normally separated out in classic N-Tier patterns - domain object module, business rule module, data module, api module, webapp module, etc.
- Enabled by applying top level code quality checks in the parent POM (checkstyle, PMD, etc)
- Enabled by applying top level doc generation in the parent POM (JavaDocs, maven sites, etc)