Arnaud Bailly wrote:
I am investigating how to create "reproducible" builds with maven2. There is a proposal from Brett Porter in the wiki about refactoring local repository structure that goes in that direction. Not sure however when it will be available. Enforcers and requirements also helps, as well as of course pinning pluginversions.I was however hoping to find a way to "tag" the local repository used for a build in order to be able to reproduce the latter and/or to compare local repositories produced by two builds that are supposed to be identical.
A fundamental rule underlying maven is that once an artifact is rolled, it never changes. You cannot have repeatability without this.
If your local or remote repository is changing over time, then something is very broken.
And it is surprisingly easy unfortunately to get bitten by this: the person doing the release forgets to include vital file X in their build, so rather than rerolling the release, they cheat and manually insert missing file X into their released jar file without telling anybody.
Fast forward a short while, and person Y has checked out the source for that release - minus file X - to investigate a production problem, and they get the error "file X is missing". Much time is wasted trying to investigate why they are suddenly getting the error about a missing file X, instead of the production problem they are trying to solve. This is caused because the source doesn't match the binary, it is not repeatable.
A possible solution to your problem could be hosting your local repository (which I am interpreting to mean the repository local to your organisation where you deploy your releases) on a subversion server over WebDAV.
Subversion has a very useful feature in that a repository is accessible via a normal web browser (which means maven can download artifacts without maven having any knowledge whatsoever that it is really talking to subversion).
It has a second even more useful feature giving write access to the repository via WebDAV (which means the maven release process can deploy the new artifacts to the WebDAV maven repository, again without any knowledge whatsoever that subversion is even there).
Because your maven repository is now also a subversion repository, you now have full history of who did what. If an artifact is changed, that can be searched for in the subversion history and red flagged before that jar makes it into production. And the subversion repository will have full details of exactly who overwrote the binary, and when.
Regards, Graham --
smime.p7s
Description: S/MIME Cryptographic Signature
