+1
Ron
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 trunk."
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: ctrueden.w...@gmail.com [mailto:ctrueden.w...@gmail.com] 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: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
--
Ron Wheeler President Artifact Software Inc email:
rwhee...@artifact-software.com skype: ronaldmwheeler phone:
866-970-2435, ext 102
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
