Thanks a lot for your detailed answer. The problem I am trying to solve is slightly different to the one you are pointing at: I just want to be able to control precisely what are the elements that are used in some build so that any discrepancy between two builds of the same source, which usually manifests itself as a compile or test failure, can be analyzed quickly. I do not - yet - tackle the release problem.
As I said in my previous post, there are various techniques in maven to ensure this. Those that I know and can think of are: - pluginManagement and dependencyManagement with all versions of plugins pinned down - prerequisites - enforcer plugin It seems to be that a great deal of trouble is alleviated by pinning down precisely what artifacts you are using for the build (not the artifact you are producing), plus a couple of other things in the environment. While I am aware of those various techniques and think they are good practices that should be followed, I was wondering whether a tool that could "compare" the local repository (ie. not the local in corporate way, local in maven way) with some other build's repository "signature" would be useful. I have all too often been beaten by local succesful build (on the developer's workstation) that yield failure on CI because some dependency was added that had unexpected side-effects or the environment is uncorrectly set (for whatever reasons),... I am also aware that discipline and rigor always help in developing software, but we are mere faillible mortals :) I knew about SVN's HTTP features but thought that its WebDAV's ability was somehow special (using something called DeltaV ?) and could not be used by "mundane" DAV enabled wagon. Thank you very much for the tip. But the local repository is accessed through filesystem so that I would need further processing to version it. Maybe I could use a custom ArtifactRepository that would version each run in a local mercurial depot ? That explains my interest in tools working with repositories: I could use that to synchronize 2 local repositories, or to ensure that only some artifacts are present and compare expecter/actual repository structure... Regards, -- Arnaud Bailly, PhD OQube - Software Engineering http://www.oqube.com --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
