We have migrated all of our internal code to Maven now. We have many separate top-level projects and many of these projects are multi-module projects. We have done a good job of moving common code elements out to their own project so they can easily be reused. Generally speaking from a basic object-oriented architecture standpoint, we are happy with how we have architected our code.
However after all of that good work, we have run in to a slight drawback when it comes time to make releases of our code. There is no way we are the biggest code base out there using Maven, so I am hoping someone can help us with this issue. Imagine we have Project-A - it is a multi-module project and the main artifact it produces is a JavaEE application packaged as an Ear file. However this project depends on our shared company-wide uberpom, it also depends on 3 or 4 Java services that are in their own projects and it also depends on our internal commons library also in its own project. Depending on what has happened since the last release, Project-A may be depending on SNAPSHOT versions of some or all of these other Projects. So to make a release we have to first make releases of the other Projects (and also any SNAPSHOTS they depend on etc. etc.). Then as we work our way back up the dependency tree we have to edit pom files to change the SNAPSHOT dependencies to the just released version numbers. And finally we can release Project-A. This is a very time consuming process for us. This is a very real world problem, we recently did a release that ended up causing us to release 13 separate projects. So there seems to be 3 possible conclusions: - There is any easy way to make these kinds of cascading releases, but we just don't know about it - There is a better way to structure our Maven projects so this doesn't happen in the first place (keeping in mind that we are happy with how the code itself is architected currently) - This is just the way it is, so we should get used to it Can anyone comment on this? Thanks ------------------------------------------------------------------------------ Craig Dickson Software Engineering Manager Behr Process Corporation Santa Ana, California _________________________ The information contained in this e-mail message may be proprietary, privileged, confidential or protected from disclosure. If you are not the intended recipient, any dissemination, distribution or copying is strictly prohibited. If you think that you have received this e-mail message in error, please e-mail the sender.