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. 

Reply via email to