Hi Phillip, Phillip Hellewell wrote:
> 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? We do this for years with a quite large project base. > 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. It's not as bad as it looks, because either the "higher" component is using an older released version of the parent - then it does not care about the newer stuff - or it is supposed to build against the lastest artifacts, then you need to build anything using the snapshot parent anyway. The only drawback is, that the developer that sets an own artifact to SNAPSHOT, should also do so with all the projects depending on it (at least with the ones that aggregate dependencies, i.e. ears, wars and ejbs if you use a classpath entry in the manifest). > 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. Actually we're using a big property section in the parent for all artifacts (and plugins) managed in its dependency management. This has the nice effect, that if you are really in need of overwriting the version, you may simply redefine the version property. > 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.) The problem is that you need a CI tool that kicks those deps automatically. While most allow manual depednencies between build plans, I know currently none, that can interact with the fine grained dependency tree used by Maven. We have therefore "building blocks", e.g. all common libraries or individual projects. - Jörg --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
