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
