How we set up the p2 update site on SourceForge

Core P2 Update Site

Redirecting Web to FRS

We are using the project web on SF as the entry point for our update site

http://rodin-b-sharp.sourceforge.net/core-updates

In the 'core-updates' web directory, we put a single '.htaccess' file:

RewriteEngine On
RewriteRule (.*) http://sourceforge.net/projects/rodin-b-sharp/files/Core_Update_Site/$1/download [L]

that redirects all requests to the FRS.

Storing Update Site on FRS

The 'Core_Update_Site' directory in the FRS contains the update site, with its usual contents:
artifacts.jar binary content.jar features plugins

When we produce a new version of the update site, we simply replace the files in this directory

Plug-in Update Site

For the plug-in update site

http://rodin-b-sharp.sourceforge.net/updates

we adapt the previous technique and use another trick.

Redirecting Update Site and Plugins Separately

For plug-ins, the jars are uploaded by the developers in separate folders of the FRS. So we have to redirect update site requests to the update site location, and artifact download requests to the FRS as before.

Here comes the other trick: using the SVN repository as update site server. The '.htaccess' file under 'updates' web directory contains

RewriteEngine On
RewriteRule ^content\.jar$ http://svn.code.sf.net/p/rodin-b-sharp/svn/trunk/RodinUpdateSite/org.rodinp.updateSite/content.jar [L]
RewriteRule ^artifacts\.jar$ http://svn.code.sf.net/p/rodin-b-sharp/svn/trunk/RodinUpdateSite/org.rodinp.updateSite/artifacts.jar [L]
RewriteRule features/(.*) http://downloads.sourceforge.net/rodin-b-sharp/$1 [L]
RewriteRule plugins/(.*) http://downloads.sourceforge.net/rodin-b-sharp/$1 [L]

Thus, in order to provide a new plug-in (or a new version of a plug-in), the developers simply

• put their jars in the FRS in their own directory
• commit the updated update site (content.jar and artifacts.jar) to the SVN repository (commit = publish)