John Casey's dashboard

The best way I've seen multi-module builds used is for separating extension or client APIs from the rest of the implementation code, and also to enforce certain architectural design elements.

First, for separating extension APIs and client stubs, multi-module builds ensure that your API/stub code is clean and can be separated from the implementation code without worry. It also has the clear benefit of producing _much_ smaller binaries for plugin/client developers, since they have only what they need to get the job done (eg. component interfaces or communication protocols). In effect, these modules are sort of a slave to the main build in that they are identified in terms of the main project - groupId and version, and even artifactId prefix usually. When a new Foo-application comes out, a new Foo-client and Foo-ext-api are released in lock step, and never is Foo-client released without Foo-application...at least, in normal circumstances.

On the other hand, there may be times when you have specific layering within the architecture of your application...layering that you want to remain distinct, in order to prevent creating a gridlock situation where so many nearly-circular dependencies have been created between components in the different layers that you can't adjust to the future needs of the business. I've worked on large, spread-out teams before that had large numbers of consultants and greenhorns on board, and this "seizing up" effect caused constant problems. Finally, we wound up splitting our application build according to layer - data, service, view, and so on - and assigning strict dependencies between them. This way, if a developer violated the architecture by introducing a bidirectional dependency between layers, the build would fail. This was incredibly hard to do in Ant (our build tool at the time; this was before Maven), but it was worthwhile.

As for your situation, where you have projects that are libraries used in multiple projects, it seems like you have a much more complex release cycle for these libraries. In other words, your utils project may have a new released associated with the release of any of projects {A, B, C, ...}. These releases have a rippling effect on the other projects than the one which caused the utils release, and it sounds like you're handling it fairly well. The use case you have - keeping all trunks up to date with the latest release - isn't actually addressed explicitly within Maven. Currently, my advice would be tthe approach you've implemented; some sort of custom plugin that can update all projects in {A,B,C,...} based on a new release of utils...sort of a reverse-dependency mapping. Nexus can help here by untangling the locations of binaries for things like utils releases, but unfortunately we don't have a standard solution for the rippling update problem yet.

I hope this answers your question.