Moving to Mercurial (or rather, moving to a distributed SCM development style)
should help us solve this problem. As I remember, here's how Solaris deals
with similar issues...
Below the master workspace are a bunch of integration workspaces (gates)
used by different teams. Each workspace has associated with it a set of
already built binaries corresponding to the sources in the workspace. A
developer's workspace might have only one or two modules in it, but will
depend on the prebuilt modules in the parent workspace. A developer would
only publish binaries to his own (local) repository. The integration gate
keeper would publish binaries to the repository associated with the
integration gate. Only release engineering would publish binaries to an
"official" public repository. (Although each of the integration repositories
would also be available to the public, they just wouldn't correspond to any
well-defined release of the product.)
This is a grossly simplified description of what I think we should be doing.
The key is that there is not just one workspace or one maven repository.
This approach provides a consistent set of binaries for use by developers
while isolating developers from unexpected changes.
Hopefully we'll soon publish our plan for how we're going to manage our
Mercurial workspaces. We can learn a lot from how OpenSolaris and OpenJDK
are managing their workspaces.