maven-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ron Wheeler <>
Subject Re: Reducing SNAPSHOT redundancy
Date Tue, 08 May 2012 13:26:15 GMT
On 08/05/2012 8:39 AM, Thiessen, Todd (Todd) wrote:
> In my experience, I notice a certain lifecycle with builds.  They start off relatively
small but as the releases and years pass, the build grows and evolves.  More things get tacked
on, more modules get added, and so forth.
> I find that over time, the earlier modules of the build change less and less. There can
be any number of reasons for this (feature content for that area is relatively stable and
needs fewer and fewer enhancements, etc..). Whatever the reason, what this tells me is that
those modules no longer need to be built over and over again. They can be broken out into
their own trunk and built and versioned independently.  This would shorten your build time,
which is vital in a CI kind of environment where you want to have a change tested and get
feedback on the build as quickly as possible.
> Now 30 modules is still relatively small.  I am not sure how long your turn around time
is. I start to get a bit concerned once a build approaches 10 minutes.  Once it does, I start
to ask questions like "Are all modules of this build changing constantly?  If not, which ones
are not and why? Which of these can and should be considered to be pulled out into their own
> I find that this line of thinking not only helps to keep all build times fast, but it
also helps to keep a healthy high quality code base which promotes re-use.
> Anyway, that's my 2 cents.
>> -----Original Message-----
>> From: [] On
>> Behalf Of Curtis Rueden
>> Sent: Monday, May 07, 2012 4:32 PM
>> To: Maven Users List
>> Cc: Johannes Schindelin
>> Subject: Reducing SNAPSHOT redundancy
>> 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:

Ron Wheeler President Artifact Software Inc email: skype: ronaldmwheeler phone: 
866-970-2435, ext 102

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

View raw message