A common sticking point with people looking at Maven is the concept of using a remote web repository (even if they can mirror it in their local network) rather than storing the dependencies in CVS along with their source code.
Usually when the arguments here take place, the benefits of putting them into an SCM (such as versioning, access control and auditing) are touted as reasons to store them with the project and live with the downsides of duplication, slower checkouts and updates, and reliance on SCM versioning that can leave you stranded when the files are later deployed and have nothing attached to them to indicate where they came from.
It is only the latter problems that Maven attempts to solve by having a repository, so why not have the best of both worlds?
I came to think of this when I saw the argument yet again on the users list and thought back to
a discussion about using Subversion as a remote repository.
Given it was a Friday, I decided to spare a couple of hours and implemented it.
It’s pretty rough, but is a working prototype that makes Maven 1.1/2.0 downloads a checkout/update, and deploy is an add/commit. I see this would be useful for snapshot repositories, where you could use one filename instead of transforming the version, so getting the latest would literally be an svn update.
I don’t know if I’ll come to use it myself, but if anyone is interested in testing and working on the functionality, please drop by the developer mailing lists.
Working with the new components of Maven makes things like this really easy – in the couple of hours I was able to reuse the existing upload/download mechanism, and wrap it around our SCM handlers, so CVS and SVN could both be plugged in. With a little testing so could clearcase, starteam or perforce which we have alpha providers for, or anything else someone cared to work on (we have had interest in developing a VSS provider, for example). All of this is reusable against all of the Maven plugins, and any related Ant tasks.