Interesting ideas, thanks. By "aggregation jars" I assume you mean like intermediate components with no actual code but that serve to manage versions. I think that is a neat idea.
Phillip On Mon, Feb 28, 2011 at 10:23 AM, Ron Wheeler <rwhee...@artifact-software.com> wrote: > Our move to aggregation jars was our solution of this problem. > We wanted central control over versions without a lot places to manage > version numbers. > For each application release, we decide what third versions of third party > libraries will be used. > If any of the libraries need changing we create the updated versions. > > We used to create new versions of all of the libraries but we stopped since > it was a lot of work for nothing. > The cost is that version 1.11.2 of the application depends on 1.9.1 of the > CXF webservice libraries. > > We maintain a simple spreadsheet of components so that everyone knows what > they are supposed call on as versions of the 5 or so dependencies that gives > them their 60+ libraries required to build our application. > > We generally do not make or use SNAPSHOTs for these libraries so that > simplifies the process. > > I hope that this helps. > > Ron > > On 28/02/2011 11:49 AM, 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? >> >> 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 >> >> > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > For additional commands, e-mail: users-h...@maven.apache.org > > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
