So I have a couple of projects over at Sourceforge.net; no, not a top 10 project, but a couple of small Java utilities. Choosing Convention over Configuration, all these projects are built with Apache Maven. Now, Maven projects use Maven repositories for getting their repositories as well as deploying their artifacts. This can be a challenge if you are hosting your project on SourceForge and using Maven.
Sourceforge provides a lot of features for hosting projects, but one nice to have missing feature for SourceForge is a maven repository. You can of course use Maven Central repository to get the dependencies for your project (provided someone uploaded your dependency to Maven Central), or you can use any other public repository like the ones over at Apache, JBoss, Codehaus or Sonatype. You have your little challenge if you have a dependency which is not in a public maven repository, but you can get around it, either putting stuff in your Subversion repository or installing the dependency to your local maven repo.
Question is, how do you distribute your project for someone to consume through Maven? Sourceforge provides you an excellent distributed, mirrored File Release System, but it is not a Maven repository. It of course does not need to be, Sourceforge is a generic hosting provider not specifically designed for Maven projects, not even for Java projects. So, what are your options:
- Sourceforge Project Web Host – could be an easy option to host your release files, but it is discouraged by Sourceforge staff and of course you not only lose out on the features of the FRS, but also puts extra load on the web host.
- Subversion Repository – Taking advantage of Subversion’s HTTP/DAV feature, you could expose your files as a Maven repository through your Subversion SCM host (In fact I have done that for one of my projects, see – https://mindtreeinsight.svn.sourceforge.net/svnroot/mindtreeinsight/maven-repo/trunk/release/). But again, you lose out on the features of the FRS.
- Release your files on Maven Central – The good folks over at Sonatype allow open source projects to upload their projects to Maven Central through the Sonatype OSS Maven Repository. Read more about it here. And what more, they even let you see the stats of your project’s usage and download stats (see Now Available: Central download statistics for OSS projects). Review the Maven Central Guide and as far as possible use Maven Central to upload and deploy your artifacts.
All of that sounds great, except I have a couple of challenges. First, I refuse to add org.sonatype.oss:oss-parent as the parent of my POMs. Second, I cannot back the group ids of my two projects with an actual website. All my projects have a group id of com.mindtree.techworks.*, but there is no techworks.mindtree.com domain on the internet! Infix and Insight started life as internal projects in MindTree which were later open sourced.
My solution, to expose multiple data sources as a Maven HTTP repository using PHP. The PHP script with its configuration would hold and manage the directory map and artifact locations and would send HTTP 302/301 redirects to the real locations when enquired by Maven. And this whole info can be generated using directory scanning, some configuration and velocity at site generation stage of a Maven project… sounds like a Maven plug-in? It is!
Thus began Infix SourceForge.Net Maven Repository Plugin. The work on this plug-in is not complete yet, the under-development source code is on the Infix Subversion repository at https://mvn-infix.svn.sourceforge.net/svnroot/mvn-infix/plugins/sfnet-mvnrepo-plugin/trunk/, the issue tracker is the Infix Mantis BT instance; and when released the plug-in will be documented on the Infix site at http://mvn-infix.sourceforge.net/sfnet-mvnrepo-plugin/. And what more – it will be self hosting 🙂 The planned maven repository for this is http://mvn-infix.sourceforge.net/m2repo/.
There is one challenge with using repositories generated by this plug-in though. Due to a defect in Lightweight HTTP Wagon (WAGON-314), the default Maven installation cannot handle 301/302 redirects. Until this is fixed, the workaround is to use the HTTP client HTTP Wagon, instructions at the Maven Guide to Selecting Alternate Wagon Providers.
Now on to writing some code for the plug-in…