Archivable, replicable releases when building with Maven: is there a right way?

We have a largish standalone (i.e. not Java EE) commercial Java project (10,000+ classes, four or five SVN repositories, ten or twenty third-party libraries) that's in the process of switching over to Maven. Unfortunately only one engineer (in a team of a dozen or so distributed across three countries) has any prior Maven experience, so we're kind of figuring it out as we go.

In the old Ant way of doing things, we'd:

1. check out source code from three or four repositories
2. compile it all into a single monolithic JAR
3. release that (as part of a ZIP file with library JARs, an installer, various config files, etc.)
4. check the JAR into SVN so we had a record of what the customers had actually got.

Now, we've got a Maven repository full of artifacts, and a build process that depends on Maven having access to that repository. So if we need to replicate what we actually shipped to a customer, we need to do a build against a Maven repository that has all the proper versions of everything. This is doable, I guess, if in (some version of) the (SVN-controlled) POM files we set all the dependencies to released versions?

But it gives our release engineer the creepy-crawlies, because there doe开发者_StackOverflow社区sn't seem to be any way:

1. to make sure that somebody doesn't clobber the copy of foo-api-1.2.3.jar on the WebDAV server by mistake (the WebDAV server has access control, but that wouldn't stop a buggy build script)
2. to detect it if they did
3. to recover afterwards

His idea is, for release builds, to use a local file system as the repository rather than the WebDAV server, and put that local repository under SVN control.

Our one Maven-experienced engineer doesn't like that -- I guess because he doesn't like putting binaries under version control? -- and suggests that maybe the professional version of the Nexus server can solve the clobbering or clobber-tracking/recovery problem.

Personally, I'm not happy (sorry, Sonatype readers) with shelling out money for a non-free build system when we haven't even seen any benefit from the free version yet, and there's no guarantee it will actually solve the problem.

So our choices seem to be:

1. WebDAV server
   • Pros: only one server, also accessible by devs, ...?
   • Cons: easy clobbering, no clobber-tracking/recovery
2. Local file system
   • Pros: can be placed under revision control
   • Cons: only works with the distribution script

Frankly, both of these seem like hacks to me, and I have to wonder if there isn't a better way to do this.

So: Is there a right thing to do here?

---

I'm not sure to get everything but I would:

• Use the maven-release-plugin (which automates the release process i.e. execute all the steps documented in release:prepare).
• Use WebDAV with anonymous read-only and authenticated write policy (so only release engineer can actually deploy released artifacts to the corporate repo).

There is a no need to put generated artifacts under version control (if you have the poms under version control). I don't see the benefits of using the local file system instead of WebDAV (this is not providing more security, you can secure WebDAV as well). I don't see what the commercial version of Nexus would solve here.

---

Nexus has a setting which prevents you from clobbering an already released artefact in a release repository.

For a team of about a dozen, the free version of Nexus should be enough.