When you're developing with Maven, most of your dependencies will come from Maven Central, but there are plenty of reasons why you might want to run your own repository. That could be because you have proprietary components that you don't want publicly accessible or because it makes some organizational sense to host artifacts in your own environment outside of Central.

There are a couple projects that are commonly used for this purpose. Nexus and Artifactory are the big ones, and there used to be a decent truly-open option in Apache Archiva. For a good while, I've used Artifactory primarily, and it does fine, but it's always a bit of a hassle to have a separate server running just for this purpose. It's one more thing to manage, to update, and to troubleshoot when something goes awry.

The Maven repository format is really pretty simple, though, basically a file tree with XML files at each level to describe the children, followed by the actual JAR files and other artifacts. For example, a deployment of Domino's redistributable NCSO API JAR might look like this:

The base "protocol" as such used by the Maven Deploy Plugin is similarly simple, consisting of a handful of GETs to expected metadata files followed by PUT calls to create or update the appropriate files. The plugin will do the stitching of the metadata XML files together itself, as it will if you deploy to a local repository.

In practice, repository servers like Artifactory tend to add a lot on top of this: limiting the number of snapshots per version, enforcing role-based access, proxying artifacts from upstream, and so forth. However, those features aren't strictly required for a basic repository to work.

Anyway, as I often do, I decided to take a swing at solving this in an NSF. Since my needs are low - it's usually just me or maybe another person or two publishing to a repository - I don't need to add many of the features on top. Plus, some of it is taken care of for me: if the repository is in an NSF, there's implicit authentication and authorization support via Domino's HTTP auth and the database's ACL.

Thus, yesterday, I uploaded a new project: the NSF Maven Repository. It's in an early state currently, but it should be usable for basic needs. While I don't want to add all of the usual bells and whistles, I expect I'll want to at least cap the number of snapshots per version, and there are a couple other potential management features to add.

Since I get to piggyback on the XPages JEE project, the bulk of the code is in a single REST API class, which assumes good-faith use from an authenticated client. Then, the "filesystem" structure is done via a pair of NoSQL entity classes, which mostly contain path data and, in the case of RepositoryFile, the actual attachment.

While I was at it, I made the file structure compatible with the NSF File Server project, so the NSF can be used as a data store in there. Indeed, the screenshot above is from Panic's Transmit, listing the contents of the repository over SFTP.

I'm pleased with it in this basic state, and will probably polish it a bit and put it to use. In particular, I expect I'll replace OpenNTF's Artifactory server with this, since that will cut down on an entire server to run. I'll also be able to use it in internal proprietary cases, where otherwise I've historically run Archiva. In the mean time, if you have a need for this kind of thing, give it a look.