Yet another way of configuring your multi-module build on CI is to NOT just do "mvn deploy". The key thing with CI is that you want to verify the build, right? And get quick feedback on errors. Doing "mvn dpeloy" on a larger multi-module build will not do this for the latter part of the build. So, what you want is "mvn test". You will then not waste time creating jars that you don't really need (for verifying the build). That build could then trigger a "mvn deploy" (possibly with -DskipTests) job to push to the repo. Or even better, a second step of the same job (which will ensure that it's the same code base being used and not a fresh checkout).
/Anders On Tue, May 8, 2012 at 3:26 PM, Ron Wheeler <rwhee...@artifact-software.com> wrote: > +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 > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
