Tuesday, August 11, 2009

Extracting legacy release notes on sourceforge.net

Recently sourceforge.net changed their File Release System (FRS). One of the changes affected now release notes are attached to files. With the old system you would simply enter the release notes in the submission form. With the new system you are supposed to upload a release note file and associate it with the file you want. This new system has various advantages.

The release notes of the file releases that were made before the FRS change are still present in the database, and still linked to from the files. This will probably remain active for a very long time. And according to the staff you can safely rename and move the files and still have the proper release note association. (It is probably linked through the md5 and sha1 hash of the file.)

But, it doesn't give a nice consistent picture when modern releases have a txt file next to them, and the old releases have a "release note" page. So, that's why I created this PHP script. It will parse a specific "files" page from the sourceforge project site and dump all "legacy" release notes to a text file. The files are places the same directory structure as the files are.

You can use this script at your own leisure, I'm not going to provide support for it. So use it at your own risk.

Tuesday, August 04, 2009

Eclipse update site on SourceForge

This article will explain how to create an eclipse update site on sourceforge which is compliant to the sourceforge guidelines. A lot of projects host a update site on the project's webspace. But this is not really allowed by sourceforge's TOS. You should not host downloads on the project web.

With sourceforge's recent update to the file release system (FRS) it became easier to host an eclipse update site through that same file release system. There are however some small issues you should be aware of.

Simply create an eclipse update site like usual. Now you only need to make one small adjustment to the site.xml file. To the root element <site> add an attribute with the name url and the value http://downloads.sourceforge.net/project/[myproject]/[file directory]/. Where [myproject] is the UNIX name of your project, and [file directory] is the directory where you are going to upload your site within the new FRS. Eclipse's site manifest editor does not provide a field for this property, so you have to edit the xml file by hand.

So for example, if you project's UNIX name is myproject and you're going to place the update site in the directory eclipse then the value of the url attribute should be http://downloads.sourceforge.net/project/myproject/eclipse.

After this save and build the update site and upload the files to sourceforge using the standard method.

Now this is where the primary issue lies. You can not tell people to use http://downloads.sourceforge.net/project/myproject/eclipse as the url for the update site. This does not work (see below). Instead you should tell people to use http://master.dl.sourceforge.net/project/myproject/eclipse as the url for this update site. This url points to the main sourceforge's download site. But because the site.xml contains the url attribute with the value http://downloads.sourceforge.net/project/myproject/eclipse it will download all the files from that location. That location will automatically redirect to one of sourceforge's mirrors.

Of course http://master.dl.sourceforge.net/project/myproject/eclipse is not a really nice URL to hand out to your users. There are two ways you can improve that.

1. Mirror the site.xml in your projects webspace, for example at: http://myproject.sourceforge.net/eclipse.

2. Or you can create a HTTP level redirect to that url. You could use either create redirect script on your project web (see below), or use a URL shorting service that performs a 302 or 301 redirect (sourceforge's URL shorten service does not work for that).

The reason you can not use http://downloads.sourceforge.net/project/myproject/eclipse as the location for the update site is because of eclipse's mechanism to find the site information. Eclipse searches for a several files at that location. If it receives a 404 it will continue to the next possible site information file. But that sourceforge url does not result in a 404 when you request a non existing file, and for that reason eclipse won't accept the url as an update site.

This is an example .htaccess configuration you can use in your sourceforge project web to make a shorter eclipse update site url:

RewriteEngine On
# Redirect the root requests to the master site
RewriteRule ^([^/]*)$ http://master.dl.sourceforge.net/project/myproject/eclipse/$1 [L]
# The rest goes to the auto-mirror location
RewriteRule (.*) http://downloads.sourceforge.net/project/myproject/eclipse/$1 [L]