Difference between revisions of "How we set up the p2 update site on SourceForge"

From Event-B
Jump to navigationJump to search
imported>Nicolas
(New page: {{TODO}})
 
imported>Nicolas
 
(One intermediate revision by the same user not shown)
Line 1: Line 1:
{{TODO}}
+
= Core P2 Update Site =
 +
 
 +
== Redirecting Web to FRS ==
 +
 
 +
We are using the project web on SF as the entry point for our update site
 +
<pre>
 +
http://rodin-b-sharp.sourceforge.net/core-updates
 +
</pre>
 +
 
 +
In the 'core-updates' web directory, we put a single '.htaccess' file:
 +
<pre>
 +
RewriteEngine On
 +
RewriteRule (.*) http://sourceforge.net/projects/rodin-b-sharp/files/Core_Update_Site/$1/download [L]
 +
</pre>
 +
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:<br/>
 +
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
 +
<pre>
 +
http://rodin-b-sharp.sourceforge.net/updates
 +
</pre>
 +
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
 +
<pre>
 +
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]
 +
</pre>
 +
 
 +
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)

Latest revision as of 15:31, 17 January 2014

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)