"That being said you should never need to.." - again, this is incorrect, given personal experience. While bloating the size of the repository I agree, the file will reside outside of source code folder, naturally.
I appreciate people feedback on this. However, please keep in mind that the topic is NOT best practices. I am well aware that some of the things I want to do go against Maven. However, all is based on personal experience and I don't consider Maven to be a magic pill. My experience has shown me that too many people rely on technology and automation to solve everything rather than to add some proper engineering discipline, process, ability to think out of the box, and sometime, manual steps. -----Original Message----- From: Jeudy, Guillaume [mailto:[EMAIL PROTECTED] Sent: Monday, November 03, 2008 13:14 To: Maven Users List Subject: RE: General Maven questions.... As for repositories hosted by 3rd parties, if you dont trust them why not setup your own maven2 intranet repository (which is quite easy to do by the way) and copy the dependencies you need there ? Whenever you release artifacts using the maven release plugin it will automatically generate an MD5 checksum and store the checksum file along your artifact in the remote repository. Therefore in the best of worlds when artifacts are released properly in maven repositories you don't have to worry whether the version tagged is really matching the actual artifact binaries. Storing a release binary with all dependencies will bloat your source control system and will not add any value aside from saving you a rebuild cycle if what you need is to rebuild a release. That being said you should never need to; if you use the maven release plugin (the release binary is automatically pushed to your repo configured in distributionManagement section). This is true on the assumption that you are never re-releasing using the same POM version. As for your external properties file issue I don't see another way than putting your properties file inside a jar and publish it as a maven artifact, this way you can use the dependencies section to refer your shared jar in other projects and have your properties file available on the classpath. Cheers, Guillaume ________________________________ From: Taub, Jonathan [mailto:[EMAIL PROTECTED] Sent: Mon 03/11/2008 2:13 PM To: Maven Users List Subject: RE: General Maven questions.... 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. ____________________________________________________________________________________________________ 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.
