Something I had on my todo-list for a long time now, setting up our internal central maven repository, got tackled today.

I had delayed this for a long time for the sole reason of having nil experience with maven. It turned out to be quite simple!

First, a maven repo server is sufficiently handled by a simple Apache document root. Second, Maven (client) takes care of the hard parts.

So all I had to get done for the initial setup was the authentication/authorization. I just reused my system for yum repositories where clients have access to any repository where I put their public key. They put the rpm in a specific directory (~/repo/) and incron/createrepo takes care of the rest. For maven it was even easier: the client did the actual work of creating the metadata!

So the repository itself was created fast enough - add a new parameter “repo_type” in my puppet module and diffentiate between the default “yum” repo and the new “maven” type (where “maven” meant “skip most steps”). A push of the module, a new entry in the hieradata and running the puppet agent gave me a new repository with some public keys having access. Great - now getting to know the client :-)

I got the client itself to deploy directly to the maven repository over sftp, but actually this was unnecessary. Only after this I discovered that Jenkins could do this (and do this better and more elegantly). This allowed me to couple a project in Jenkins with a (the) maven repository, and I didn’t need to collect public keys. Also, Jenkins kept track of the copy-process and the artifact if wanted.

The necessary build step is the post-build action “Deploy artifacts to Maven repository”. It takes the necessary parameters. The Jenkins master has my repo-seerver’s ssh fingerprint in it’s knownhosts and a valid private key to connect to it. The rest just works. (The master copies the jar from the build slave and uploads it via scp; not all publish plugins work that way)