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
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
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)