In fact we rarely deploy -SNAPSHOTs at all... the only time we have deployed -SNAPSHOT builds is when SV have a complex test scenario and we need to check the fix before we roll a big suite release
2009/9/4 Stephen Connolly <stephen.alan.conno...@gmail.com> > I find that we have given up on unique snapshots.... > > we just use non-unique all the time. > > if you need a unique snapshot, just roll a release, e.g. 1.0-milestone-1 > > -Stephen > > 2009/9/4 Brian Fox <bri...@infinity.nu> > > I was recently working with a customer to move them off of using >> non-unique snapshots for various reasons. In the process we discovered >> a problem with snapshots, classifiers and multi-platform builds. >> >> In this scenario, we have a project that is built on multiple >> platforms, say windows, solaris and mac. The binaries must be built on >> the target platform. The source is the same, so the gav is the same. A >> CI build actually consists of 3 builds running in parallel. Each build >> deploys a classified artifact where the classifier is the platform, ie >> [windows|solaris|mac]. >> >> When we flipped them over to using timestamped snapshots, we uncovered >> a problem. As each build finishes, maven increments the timestamp and >> build number and deploys their artifacts. The trouble is that each >> timestamped build consists of only 1/3 of the classified artifacts. So >> for example, once the Mac target is deployed, the Windows SNAPSHOT >> version is no longer able to be located because the maven-metadata.xml >> says the latest is the Mac only build. >> >> Since the source in this case is identical, having separate modules >> for this seems out of the way. Classifier really is the right way to >> distinguish between different flavors normally, but obviously this >> doesn't work well when you have to produce the artifacts from separate >> mvn invocations. >> >> It feels to me like we need some better support in Maven to handle >> these types of multi-platform builds, but I'm curious how people are >> handling it now? >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org >> For additional commands, e-mail: dev-h...@maven.apache.org >> >> >
