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
