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
