How to prevent overwriting of released artifacts (non snapshot versions) in maven repository on hudson

Question

Problem Description

Consider the case maven is being used on hudson.

Now someone took checkout of a project,modified some files but accidently used same artifact id and version number(non snapshot).

He/She then build this project on hudson and did maven install.The modified artifact is now in hudson .m2 . Any other project which depent on it will be build with modified artifact. No one finds this out if compilation doesn't fail. Even though correct artifact resides in central repository it is never used because modified one is picked up from .m2 when hudson starts building.

So i am looking for a way to prevent this accidental human error.

1. Anyway to revoke permissions of maven install on non snapshot versions (released artifacts) on hudson ?
2. Any way to compare checksums of .m2 in hudson and on in remote central repository so that checksum failures can generate warnings or fail build ?

I have already checked that there is no way to force update non-snapshots versions from central repository as they are meant to be immutable.

Purging central repository or using separate repository for each job on hudson will result in increased build times & disk space usage respectively.

Any help would be appreciated.

Answer 1

I don't think you're going to find a way to stop an install from overwriting an artifact. A repository server should have a setting to prevent deploying an updated release artifact though. See, for example, "How do I disable artifact redeployment" for Nexus.

Answer 2

Here is how we manage versions in our project:

We work on a SNAPSHOT version. On Jenkins, we have a Fast Build job that builds and tests this application, but fails if the version is not a SNAPSHOT. This is done by a custom enforcer (this is the opposite of the require release version enforcer).

When we want to make a release, we use a Jenkins job for that. Using the parameterized build, and Maven release plugin, the person who is in charge of doing the release will just indicate the version of the release (the stable version), the next SNAPSHOT version, as well as the name of the SCM tag. Thus, only Jenkins will define a stable version and the developers will always work on a SNAPSHOT code.

But of course, this does not prevent the developers to make what he wants on his local machine. But we always consider one trusted place: the Jenkins server. It works on my machine is never a good answer to a problem ;o)

Answer 3

There was no direct way to solve this but we solved this inderctly by writing a cron-job which runs every five minutes and marks all the jars which are NON-SNAPSHOT as read only in the local repository of Hundson . In this way when some project in Hudson tries to overwrite it my mvn install or mvn deploy it fails in overwiriting the artifacts as they are readonly.

Any new artifacts to be realeased can easily be written. Once written within next five minutes script marks them as read only.

Here is code for unix script permission-handler.sh

#!/bin/bash
cd ~/.m2
date 2>&1>> permission-handler.out
find . -name '*jar' -type f | grep -v 'SNAPSHOT' | xargs chmod -vc 444 2>&1>> permission-handler.out
chmod 777 permission-handler.out

Logging is also handled to see which all artifacts have been marked as released only.