Anyone with a project on SourceForge who does Maven knows how poorly it supports maven repositories.
You can set up repos in the Apache virtual for your project, but you are limited to 100MB. That gets chewed up very fast.
Secondly, about 6 months ago they revoked ssh access. The result is that the scp wagon cannot create directories. (On a side note, the site deploy is similarly affected – it can scp the file to SourceForge but cannot unzip.) My workaround for this problem has been very frustrating. I do a deploy, which fails, but tells me what directories it was trying to create. Then I sftp to SourceForge and create the directories, then run deploy again. This is such a pain that I have given up deploying snapshots, which then hurts my users.
Now when it comes to deploying to the Central repo I have set up with them a sync for the ehcache artifacts on SourceForge. That works fine. However recently I needed to do an update to jsr107cache, the draft API for JCACHE. This one is not synced. I have been waiting a month plus for action on the manual JIRA upload process to get that deployed to central, the result being that someone has logged a bug against a the ehcache-jcache module saying there is no jsr107cache. Now it is available on my SourceForge repo but that takes more work for people to figure out.
So, in summary, SourceForge is not doing a good Maven job. As a past SourceForge project of the month, I thought I should try to get them to fix things. The last thing I want to do is to move my project, with all the hassle that entails. One thing I like about SourceForge is that you retain complete control over the projects you own. There is no benevolent dictator who can sweep in and take over your project. Ross Turk of SourceForge has been quite responsive to my suggestions, but I think they have a lot of projects to manage and Maven is a Java thing. Java is just one of the many languages there projects are written in.
I have now taken up an offer from Jason Van Zyl for free hosting of my primary repository at http://oss.sonatype.org. It is synced with central, so my jsr107cache problems are over. No distribution problems either.
<distributionManagement>
<repository>
<id>sourceforge-releases</id>
<name>Sourceforge Release Repository</name>
<url>http://oss.sonatype.org/content/repositories/sourceforge-releases</url>
</repository>
<snapshotRepository>
<id>sourceforge-snapshots</id>
<name>Sourceforge Snapshot Repository</name>
<url>http://oss.sonatype.org/content/repositories/sourceforge-snapshots</url>
</snapshotRepository>
</distributionManagement>
I have already started deploying snapshots to this repo.
The full contents of the old repositories at http://ehcache.sf.net/repository and http://ehcache.sf.net/snapshotrepository have been migrated to sonatype by the guys there. I have deleted the old repository to avoid confusion.
At sonatype my stuff lives in a SourceForge repository. Any other SourceForge based projects wishing to host their Maven repos there should contact the guys at Sonatype, as this will be simple for them to set up.
oss.sonatype.org runs on Nexus, a new Maven Repository Manager (“MRM”). It makes a lot of sense to use an MRM inside your company. While a dumb Apache directory works, there is so much more you can do with an MRM. Searching, proxying externals and providing developer friendly metadata are top of my list. Nexus is dual sourced, with a community edition giving most of what you want, and things like LDAP for security available in the licensed version. And of course, uses ehcache :).
Using a smart primary repo, which is then synced to central is better for quality too. As Jason says,
“if we could get enough projects to use the Nexus gateway then we can really start taking real measures to have signatures, sources, javadocs and even check that transitive closures are intact. Basically prevent any shit from getting into the central repository and making it easier for projects to get artifacts to central.”
