maven-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Phillip Hellewell <>
Subject Re: Dependency version management
Date Mon, 28 Feb 2011 19:39:43 GMT
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.


On Mon, Feb 28, 2011 at 10:23 AM, Ron Wheeler
<> 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:
>> For additional commands, e-mail:
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message