Each person has his/her own experience. I have had the unfortunate experience that builds cannot be reproduced, when the entire build is performed automatically (bugs do exist elsewhere). So this is not a myth. I even came across a scenario that on rare cases, creating a .jar file using the exact same compiler and JVM resulted in different file sizes for whatever reason.
I am considering it from a bitter, bitter experience. At least having the knowledge that whatever the build you have cannot be reproduced for whatever reason, can be an important piece of information. Automation of repeatable tasks is definitely the way to go in this case. HOWEVER, I do want to have the assurance that at any given point of time, I can put my hands on the EXACT binary that was deployed to production X amount of time ago. The ONLY way to ensure that is to retain a copy of that binary. -----Original Message----- From: Graham Leggett [mailto:[EMAIL PROTECTED] Sent: Monday, November 03, 2008 12:29 To: Maven Users List Subject: Re: General Maven questions.... Taub, Jonathan wrote: > I understand your concern. > However, the application itself is self contained and is not meant to be a > third party > application/library. Each release is tagged in Subversion, proper release notes are > maintained, and the application will contain a web page specifying the current > build/version. It makes no difference - when you have a problem, your troubleshooter will hold in their hands the deployed binary. And while they might think they are holding version X, but they're actually holding version Y because someone "forgot" to update the docs, and they waste hours trying to figure out where the confusion lies. From bitter bitter experience, don't even consider it. Or, if you do, don't be surprised if a troubleshooter chases you down with a rolling pin. > Right now, changing multiple pom files each time before a release is a > headache (and > then changing it back to snapshot). Which is why you don't do it, you use your computer and the maven-release-plugin to do it for you. The release plugin will let you release single jars at a time, or it will happily let you release a multi pom project. The release plugin will run your tests, check that your code is checked in properly, change the version numbers to the released version, check in the release version numbers, tag the new version, bump the released version again back to snapshot, commit the new version numbers, check out a pristine copy of your new release, build the release, build the documentation for the release, upload the released code to your maven repository, and upload the documentation to your documentation website, and the commands to do all this are as follows: mvn release:prepare release:perform And that's it. And if it bombs out half way through, just run the goals again and maven will continue where it left off. If you change your mind and want to rather roll back to how you started, you do this: mvn release:rollback Masochist (n): person who releases code manually without the release plugin. > Regardless of how one sets an identifier of some sort for a release > number, it is going to be manual (unless one goes only by build number). > > I have done my share of deployments and tracking versions and find this > way to be the best. I also believe in checking final binary into a > versioning control system as the ONLY %100 sure way of knowing whether > a build can be reproduced is by checking the final product of the build > (one of the reasons I want to strip Maven files from artifacts). This is a myth. If you check your binary in, what do you have? A binary. Where did it come from? No way to tell. Did someone make a mistake and check the binary into the wrong place? No way to tell without explicitly picking apart evidence. If you want repeatability, remove the human being from the equation entirely. Make sure the version number is tagged on to absolutely everything, and smack any human who tries to manually fiddle with the version number with a rolled up newspaper. Computers are repeatable, humans are not. Regards, Graham --
