You might want to look into cutting a real release. You only have your artifacts in snapshot versions (1.0-SNAPSHOT) and use the maven release plugin to cut release in non snapshot version (1.0). The release prepare goal creates the 1.0 version and tags the source code in your scm. You then create the 1.0 version using the perform goal. You can repeat the perform goal as many times as you like, which means even if someone deletes 1.0 or corrupts it some other way you can always re-perform the release. Niki
On 24/10/2007, Olivier Dehon <[EMAIL PROTECTED]> wrote: > You can set the files to read-only in the file system. > > -Olivier > > Leder, Leslie (NSN - DE/Greifswald) wrote: > > Hello, > > assume there is a module A already deployed in version 1.0. Now somebody > > changed the code of module A but forgot to increment the version so it > > still is 1.0. > > So the second version of component A is definitely not ok. But how can I > > protect the correct version 1.0 of component A than? The way it works I > > know is that the deploy plugin would just overwrite the correct artifact > > by the newer but incorrect one. Is this really ok. This would double me > > fault score to two. Now I haven't only an attempted version 1.1 but I > > also haven't a real 1.0 anymore. > > Is there any chance to let Maven2 check if the artifact that is > > currently to be deployed differs in size and/or checksum to an already > > deployed artifact in the target repository with exactly the same Maven > > coordinates (groupId, artifactId, classifier, version, type). > > > > Thanks, > > Leslie > > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
