I'm thinking about moving all our version management into the parent pom in a dependencyManagement section, but I'm trying to figure out if it will really make things easier or not.
Of course each version number would only be in one place instead of N places, where N is the avg # of reverse dependencies. So that is good. But when changing the version # of a component, you still have to update N places, to update them to the latest parent. That is, unless you are using a snapshot for the parent, but is that a normal/recommended practice? The problem I see with using a snapshot for the parent is it doesn't allow you to make changes in a safe way. I could update the version # of a lower component, and then a much higher component could build against that before all the middle components are built/deployed. This may not be a problem for Java or C#, but for C/C++ with headers and static libraries, it is a recipe for disaster. We're talking about things like inexplicable run-time crashes. By having version management in each pom itself, I can safely make a change to a lower component by upping the version # of its reverse dependencies at the same time I update them to use the new version of the lower component, and then follow that pattern as I go all the way up the chain of dependencies. Of course a continuous integration tool could be used to build all the reverse dependencies up the chain for you, and such a tool is much easier to set up when it doesn't have to worry about changing version #s in the pom, but that still leaves open a possible race condition. It could be only halfway through building/deploying all the components when a developer tries to build a high level component and runs into the problem I described. Some of our components take a long time to build, so there is a very real risk of this race condition. So I don't know if it is worth it. But maybe it is especially if it saves us time of building things manually (which we have to do now because I haven't found a tool that can kick off builds of reverse dependencies, and also up the version numbers along the way.) Phillip --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
