There seem to be several ways to structure parent poms in a multiproject build and I wondering if anyone had any thoughts on what the advantages / drawbacks are in each way.
The simplest method of having a parent pom would be putting it in the root of a project i.e.
myproject/
myproject-core/
myproject-api/
myproject-app/
pom.xml
where the pom.xml is both the parent project as well as describes the -core -api and -app modules
The next method is to separate out the parent into its own subdirectory as in
myproject/
mypoject-parent/
pom.xml
myproject-core/
myproject-api/
myproject-app/
Where the parent pom still contains the modules but they’re relative, e.g. ../myproject-core
Finally, there’s the option where the module definition and the parent are separated as in
myproject/
mypoject-parent/
pom.xml
myproject-core/
myproject-api/
myproject-app/
pom.xml
Where the parent pom contains any “shared” configuration (dependencyManagement, properties etc.) and the myproject/pom.xml contains the list of modules.
The intention is to be scalable to a large scale build so should be scalable to a large number of projects and artifacts.
A few bonus questions:
- Where is the best place to define the various shared configuration as in source control, deployment directories, common plugins etc. (I’m assuming the parent but I’ve often been bitten by this and they’ve ended up in each project rather than a common one).
- How do the maven-release plugin, hudson and nexus deal with how you set up your multi-projects (possibly a giant question, it’s more if anyone has been caught out when by how a multi-project build has been set up)?
Edit: Each of the sub projects have their own pom.xml, I’ve left it out to keep it terse.
In my opinion, to answer this question, you need to think in terms of project life cycle and version control. In other words, does the parent pom have its own life cycle i.e. can it be released separately of the other modules or not?
If the answer is yes (and this is the case of most projects that have been mentioned in the question or in comments), then the parent pom needs his own module from a VCS and from a Maven point of view and you’ll end up with something like this at the VCS level:
This makes the checkout a bit painful and a common way to deal with that is to use
svn:externals. For example, add atrunksdirectory:With the following externals definition:
A checkout of
trunkswould then result in the following local structure (pattern #2):Optionally, you can even add a
pom.xmlin thetrunksdirectory:This
pom.xmlis a kind of “fake” pom: it is never released, it doesn’t contain a real version since this file is never released, it only contains a list of modules. With this file, a checkout would result in this structure (pattern #3):This “hack” allows to launch of a reactor build from the root after a checkout and make things even more handy. Actually, this is how I like to setup maven projects and a VCS repository for large builds: it just works, it scales well, it gives all the flexibility you may need.
If the answer is no (back to the initial question), then I think you can live with pattern #1 (do the simplest thing that could possibly work).
Now, about the bonus questions:
Honestly, I don’t know how to not give a general answer here (like “use the level at which you think it makes sense to mutualize things”). And anyway, child poms can always override inherited settings.
The setup I use works well, nothing particular to mention.
Actually, I wonder how the maven-release-plugin deals with pattern #1 (especially with the
<parent>section since you can’t have SNAPSHOT dependencies at release time). This sounds like a chicken or egg problem but I just can’t remember if it works and was too lazy to test it.