maven-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brian Topping <>
Subject Re: The joys of dependencies
Date Fri, 05 Nov 2010 21:42:51 GMT

On Nov 5, 2010, at 4:56 PM, Phillip Hellewell wrote:

> I'm guessing you also update the parent pom's version each time the
> dependency management section changes, yes?

Are you keeping in mind the impact that SNAPSHOT versions have on your build?  A released
version is like a point on a line or an instant in time, whereas snapshots are the distance
between points.  Snapshots can be for your own use only (with the 'install' goal) or to share
with others who have access to a shared remote repository (with the 'deploy' goal).  If I
am using snapshots, I don't have to change the version every time I make a change, since someone
else's build that depends on the snapshot I deployed to our shared repository will check that
repository with every build to make sure it has the latest.  In other words, if I deploy a
new snapshot with a changed dependency management section, it will be picked up by others
(including CI) when they run a build.

I've found CI systems to be the easiest way to manage this complexity, but I haven't found
a self-maintaining way to get them to trigger with the granularity necessary to just build
based on changes.  For instance, I can add one SCM repository trigger to a top-level build,
but that just triggers CI to rebuild everything.  I believe this is not what you want because
if CI deploys new snapshots for everything, the binaries for everything built will look stale
to all the developer desktops that share the repository that CI pushed to.  On the other hand,
if I have hundreds of modules and I need to create a separate SCM triggers for each one of
them, the effort to maintain the build shoots way up.  It would create the desired granularity,
but I haven't had a case that this would be worth it yet.

But I think your original observation of using version ranges is correct.  

Anyway, if you have a build that is this complex, you may need someone to wear the release
management hat.  Maven doesn't make the problem less complex, it just does most of the work
for the solution.  It won't stop people from having variations on what the correct answers
are (i.e. when to change versions), hence the need to have a single authority that manages
procedure the same way every build.

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

View raw message