maven-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Curtis Rueden <>
Subject Re: Reducing SNAPSHOT redundancy
Date Mon, 07 May 2012 21:07:55 GMT
Hi Anders,

Thanks for your reply.

> 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
> setups.

Indeed, our Nexus is set to purge old snapshots daily, deleting any that
are more than 7 days old. This works just fine.

This is very helpful since it effectively bounds the disk space requirement
based on the number of builds that happen in a 7-day window.

However, my concern is more regarding the fact that the snapshot binaries
"cycle" all the time. That is, they are being continually replaced with new
builds, which may in fact be based on identical source code, every time
someone pushes to the Git repository. The unfortunate side effect is that
all developers on the project generally have to redownload all submodule
JARs once every 24 hours (whenever Maven snapshots are refreshed).


On Mon, May 7, 2012 at 3:53 PM, Anders Hammar <> wrote:

> 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
> setups.
> /Anders
> 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:

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