maven-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Anders Hammar <>
Subject Re: Reducing SNAPSHOT redundancy
Date Mon, 07 May 2012 20:53:01 GMT
I believe the common way to handle this is to schedule purging of old
snapshots in the repo manager. At least that's how I handle it in my


On Mon, May 7, 2012 at 10:31 PM, Curtis Rueden <> wrote:
> 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?
> Thanks,
> Curtis

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

View raw message