Regardless of the versioning control system being used (CVS, Subversion, etc.), I agree, that generally, it should include source files only. HOWEVER, depending on your build, you may have more than one repository. Each of the repositories is hosted by a 3rd party which has no obligation whatsoever, to retain that repository over time. And as we are all humans that can make mistakes, somebody may update a repository file without changing the version (mistakes do happen).
In short, the ONLY way to know that a build is reproducible is that the final build product is identical to whatever was deployed to production/staging. This can be accomplished by having MD5, checksum, or actual file comparison. If one uses MD5/checksum, one can establish whether the build was reproduced successfully. However, in case it hasn't (for whatever reason), the ONLY way to actually have an identical build is to have the actual file which was built and deployed at the time. While this scenario may not happen so often, I did come across it. As for external properties file, I don't need one in order to filter out resources. I just need to have multiple values shared across Maven projects and was hoping to centralize these in a single properties filed that can be referred from pom files. -----Original Message----- From: Jeudy, Guillaume [mailto:[EMAIL PROTECTED] Sent: Monday, November 03, 2008 10:57 To: Maven Users List Subject: RE: General Maven questions.... You can use maven release plugin to help alleviate the burden of updating the versions in the pom files. Also isnt it the whole point of CVS tagging combined with maven build to reproduce exactly the same binaries ? I would strongly advise against checking any sorts of binaries in your source control. Source control is *well* meant for source files. To answer your last question, yes it is possible to have an external properties file that you can use for filtering resources. Just supply it on the command line. mvn install -Dmypropsfile=<filepath> inside your pom: <filters> <filter>${mypropsfile}</filter> </filters> ________________________________ From: Taub, Jonathan [mailto:[EMAIL PROTECTED] Sent: Mon 03/11/2008 1:35 PM To: Maven Users List Subject: RE: General Maven questions.... 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. Right now, changing multiple pom files each time before a release is a headache (and then changing it back to snapshot). 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). -----Original Message----- From: Graham Leggett [mailto:[EMAIL PROTECTED] Sent: Monday, November 03, 2008 10:25 To: Maven Users List Subject: Re: General Maven questions.... Taub, Jonathan wrote: > Recently, I decided to introduce some changes into the build process and I > was unable to figure out the following: > * I want to have the final artifact name (.jar, .war, etc) WITHOUT the > version number. The application/libraries are not meant to be a third party > and version numbers (XXX-snapshot, XXX-1.5) are not needed and I want to have > the same name each time regardless of the version. How do I accomplish this? I seriously and strongly recommend that you *don't* do this. The price of doing this is that you no longer know what version of your software you are looking at. Production is giving problems, you need to check out the source code, quick. Which tag do you check out? You have no idea. I have watched people using tools like Beyond Compare to painstakingly check whether one jar was the same as another one, just because the jar had no identifying marks on it. Save yourself the pain and the suffering: don't do it. Regards, Graham -- ____________________________________________________________________________________________________ This electronic mail (including any attachments) may contain information that is privileged, confidential, and/or otherwise protected from disclosure to anyone other than its intended recipient(s). Any dissemination or use of this electronic email or its contents (including any attachments) by persons other than the intended recipient(s) is strictly prohibited. If you have received this message in error, please notify us immediately by reply email so that we may correct our internal records. Please then delete the original message (including any attachments) in its entirety. Thank you.
