Ben Tatham's dashboard

That's a great description of the benefits of multi-module builds. We may have occasion to use them on some large projects that are more self-contained. Thanks.

So I guess the short answer is that multi-module builds are not for us. I am still curious as to what the ARE good for, but perhaps that is a different question.

It sounds, too, like our pom-updater plugin is doing the job for us right now, so I think we'll stick with that. Even using depedency management, we would still have to update parent pom version numbers every time (which we could use our pom-updater plugin for as well!) – Ben Tatham, on February 04, 2009 20:25

I'm assuming you mean a corporate pom as a parent pom to all our projects.

In fact, we do use a corporate pom (actually, a hierarchy of them, b/c of some java4 and some java6 projects, and well as some war and some jar projects, with various plugins defined). But we only define dependencies like junit and easymock there.

But then are you still stuck updating the version of the parent pom every time? Or can the parent version be left blank in the pom, so it will always use the latest.

The problem with that is:
a) The released tags would need to hard-code the parent pom version, so the build is repeatable.
b) Developers branches would potentially break whenever someone released a new util.
c) Not all of Project A, B, C, etc rely on the same set of dependencies, and I'm not sure it would really come out to a tree rather than a graph of dependencies between them.

What am I missing here? I really appreciate all the help!

I think there is a misunderstanding in our current environment. Let me walk through how we do things now -- we do use Nexus.

A change to the "util" module is required for "ProjectA"

1) Have projects for util and ProjectA in Eclipse, in subversion branches
2) Modify ProjectA pom.xml to use util's current snapshot version (and m2eclipse associates them for us).
3) Modify util and ProjectA as needed.
4) Merge changes of util from branch into util trunk.
5) Use maven release plugin to deploy util to Nexus, make the svn tag, etc.
6) Update ProjectA pom (done automatically, by our own maven plugin that walks the svn tree, and updates all the pom.xml in trunks).
7) Merge changes of ProjectA from branch to trunk.
8) (Optionally) Release ProjectA with maven release plugin, again, deploying to Nexus.

Now, the issue is not with getting the released versions into all the other projects that depend on util -- you are correct, Nexus and Maven are great for that!

This is really more of a question of: would our lives be easier in Eclipse or in some other development way if util was a module of ProjectA (and ProjectB, ProjectC, etc), instead of being a dependency like it is now. The answer may be no...perhaps we are doing what's right for us. I have just never understood the benefit of multi-module builds if that is the case, other than simply breaking a part a large project for quicker builds of sub-modules. But in that case the modules are only used by one project...

Does that make my question a bit clearer? Or more muddled?

While our modules do not have independent release cycles, per se, they are heavily shared/refactored/etc among 5 or more projects that DO have independent iterations and release cycles.

Currently, we have each module in its own trunk/tags/branches. And we release them as changes are needed for any of the given projects. We wrote our own maven plugin to keep all the pom.xml in all the module and product trunks automatically updated to the latest version of each module dependency, and Hudson notifies the user, in case they forgot to update some upstream dependency to any potential API or tests breaking. Clearly, this is not the way Maven was intended, but in our transformation from a Clearcase/Ant world to a Subversion/Maven world, this made the most sense at the time. And we like keeping all our projects up-to-date with the latest module changes -- only on the trunk, of course.

Any recommendations that would make our environment more "standard"?