Think about poms and dependendencies in the same way you would a piece of OO code. You should use inheritance, composition and aggregation appropriately to reduce change and improve stability. Don't make the mistake of thinking that inheritance is the only solution.
On Tue, 01 Jul 2008 23:39:51 Peter Horlock wrote: > Hi, > > we got a software, which is devided into serveral sub projects. > We defined a parent pom, that, besides other shared items, contains a > dependency management section to ensure all sub projects are using the same > dependencies. Also, as the "software" we are talking about is actually a > website, there is never really something like a "final version" or so - the > product is constantly under development (with a monthly release cyclus). > > Based on these preconditions, I figured out the following handling: > So far, we have the parent pom always as a SNAPSHOT version, and did not > differ between different versions of the parent pom. > So far, we have all dependencies - external as well as internal depdencies > (the sub projects themself) under dependency management. > When someone wants to change the version of a specific sub project, he does > so by editing a property in the parent pom > <mysubprojectXY-version>1.11</mysubprojectXY-version> which, on the basis > of this property, will then change the version in depdency management, as > well as the version of the sub project itself (and so keep them in sync). > This ensures all subprojects are ALWAYS using exactly the same dependencies > - external ones from other > suppliers, as well as internal ones provides by ourself. > > However, the problem now is that when someone changes something in some sub > project, he could hardly ensure this change will not conflict with a > certain other sub project that might also use this project (and as so far > we only have one version of the parent pom, all projects will always get > the latest version of the parent pom, and so will also always get all > updates from all sub projects...) > > 1. Therefore, I suppose it was better if we were using different parent pom > versions, right? > In otherwords, if someone wants to change the version of a sub project, he > would also have to change the version of the parent pom, there he would > increment the version of the parent pom, as well as the version of the sub > project. When someone else wants to use the new paret pom, he would > deliberately change the parent pom he is using, and so he would know that > he had to check for version changes and their influences on his specific > sub project. > > 2. What about the version numbers of the sub projects? > a) Is it a good idea to have them entirely managed in the parent pom (by > using a property, which is used in dependency management section, as well > as in the sub project version itself?), or > b) Is it a better idea to hard code the version of a sub project in its > pom? > > > Based on the strength of past experience, I suppose it was best to use > different parent pom version for every release, and in between to maybe use > snapshot version, plus to keep up the process of having internal as well as > external dependencies in dep. management, and to keep the version in dep. > management with the last version of a certain sub project in sync by using > properties. > > Do you agree? Or do you suggest another approach? > > Thanks in advance, > > Peter -- Michael McCallum Enterprise Engineer mailto:[EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
