Difference between revisions of "How we set up the p2 update site on SourceForge"
imported>Nicolas (New page: {{TODO}}) |
imported>Nicolas |
||
(One intermediate revision by the same user not shown) | |||
Line 1: | Line 1: | ||
− | + | = 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
Contents
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)