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 <ctrue...@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 <and...@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 <ctrue...@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-unsubscr...@maven.apache.org > > For additional commands, e-mail: users-h...@maven.apache.org > > > > >
