maven-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Curtis Rueden <>
Subject Reducing SNAPSHOT redundancy
Date Mon, 07 May 2012 20:31:57 GMT
Hi everyone,

I have a question about snapshot deployment.

I have a multi-module project with ~30 modules, all in a Git repository on
GitHub. Whenever someone pushes to the repository, a GitHub notification
hook pings our Jenkins to do a rebuild, which includes a redeploy to our
Nexus. This is all great.

However, there is a lot of redundancy between snapshot JAR files. Often, a
commit will involve only one of the 30 submodules, but all 30 will
ultimately be rebuilt and redeployed, resulting in a plethora of snapshot
versions. At any point in time, there is nearly always a "new" version of
any given submodule of the project.

I was wondering about the best way to reduce this issue. It would be nice
to only redeploy snapshots that have actually changed—or better, for Maven
(client-side) or Nexus (server-side) to detect identical snapshots and not
waste the space creating a superfluous new one. (Of course, for a variety
of reasons, comparing binary hashes between the latest snapshot JAR and the
new snapshot candidate may not be enough—especially if the build process or
CI adds some build-specific information to the JAR. But that is not really
Maven's problem...)

Alternately, we could do something on the CI side to only do the deploy if
the submodule is really known to have changed—probably involving git
reflogs etc. But that road could quickly become fraught with peril...

So my question is: is there a common Maven best practice to mitigate such
redundancy? Or do most people simply live with the proliferation of
snapshots that occurs when using a naive deployment scheme?


  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message