maven-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marcin Kuthan <marcin.kut...@gmail.com>
Subject Re: Reducing SNAPSHOT redundancy
Date Tue, 08 May 2012 12:02:20 GMT
How many build plans do you have? If I understood correctly single plan for
all modules (perhaps on aggregate pom).
Even small change in one module rebuilds all modules :-(

Let's consider to define one build plan for each module. In addition define
dependencies between build plans to reflect dependencies between maven
modules (Bamboo discovers dependencies automatically).

For sure, it requires a lot of configuration on continuous server but it
works. Only changed module and all dependents will be built and deployed.

Marcin

On 7 May 2012 23:07, Curtis Rueden <ctrueden@wisc.edu> wrote:

> 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).
>
> Regards,
> Curtis
>
>
> On Mon, May 7, 2012 at 3:53 PM, Anders Hammar <anders@hammar.net> 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 <ctrueden@wisc.edu>
> 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: users-unsubscribe@maven.apache.org
> > For additional commands, e-mail: users-help@maven.apache.org
> >
> >
>

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