Details for Uploading Main Rodin Update Site: Difference between revisions

From Event-B
Jump to navigationJump to search
imported>Nicolas
imported>Tommy
 
(28 intermediate revisions by 4 users not shown)
Line 1: Line 1:
Since April 5th, 2012, the Rodin update site has the newer p2 format.
Since April 5th, 2012, the Rodin update site has the newer p2 format.
From a release engineer point of view, the main change is that instead of uploading 'site.xml' to the rodin web space, you will just commit 'content.jar' and 'artifacts.jar' to SVN. This page explains how to generate these two files.
From a release engineer point of view, the main change is that instead of uploading 'site.xml' to the rodin web space, you will just commit 'content.jar' and 'artifacts.jar' to SVN. This page explains how to generate these two files.
If you're interested in internal details, you can take a look at [[How we set up the p2 update site on SourceForge]].
 
There are two different ways to update the main Rodin Update site :
# using the site.xml file to build an updated version of the p2 site (see [[Details_for_Uploading_Main_Rodin_Update_Site#Using_site.xml]]),
# using a script to update the p2 site from your feature repository (see [[Details_for_Uploading_Main_Rodin_Update_Site#Using_an_externally_built_feature]]).
 
If you're interested in internal details, you can take a look at [[How we set up the p2 update site on SourceForge]].<br>
There are some [[Details_for_Maintaining_Main_Rodin_Update_Site#Rules_to_follow | few rules to follow when providing contents to the main Rodin update site]], please take a look at them.
 


== Using site.xml ==
== Using site.xml ==
Line 14: Line 21:
# upload the jars generated by the build as usual in your plugin's area on [http://sourceforge.net/apps/trac/sourceforge/wiki/Release%20files%20for%20download SourceForge FRS]
# upload the jars generated by the build as usual in your plugin's area on [http://sourceforge.net/apps/trac/sourceforge/wiki/Release%20files%20for%20download SourceForge FRS]
# test remotely by uploading 'content.jar' and 'artifacts.jar' to /home/project-web/rodin-b-sharp/htdocs/test-updates on the rodin web space, and using 'http://rodin-b-sharp.sourceforge.net/test-updates' as remote update site (see [[#Remote test]])
# test remotely by uploading 'content.jar' and 'artifacts.jar' to /home/project-web/rodin-b-sharp/htdocs/test-updates on the rodin web space, and using 'http://rodin-b-sharp.sourceforge.net/test-updates' as remote update site (see [[#Remote test]])
# commit 'content.jar' and 'artifacts.jar' to SVN
# commit 'content.jar' and 'artifacts.jar' to SVN: it actually updates the Rodin Update Site itself
# test using the standard Rodin Update Site (you may need to reload it)
# test using the standard Rodin Update Site (you may need to reload it)


So 'site.xml' is no more uploaded nor committed to SVN, it is really just there to help working with 'content.jar' and 'artifacts.jar'. In particular, if for some reason you want to commit it nevertheless, take care not to commit the post 'Build' version, as it mixes everything up.
So 'site.xml' is no more uploaded nor committed to SVN, it is really just there to help working with 'content.jar' and 'artifacts.jar'. In particular, if for some reason you want to commit it nevertheless, take care not to commit the post 'Build' version, as it mixes everything up.


== Externally built feature ==
== Using an externally built feature ==
 
That's the scripted way to proceed. If you are using scripts to build your feature (that is, without a running eclipse interface):
# ensure that your build scripts produce a repository (like 'buildRepo')
# categorize the repository (see below)
# launch the 'publishFeature.xml' ant script in org.rodinp.updateSite on the categorized repository (modifying the 'featureRepo' property in the launch config) to update 'content.jar' and 'artifacts.jar'.
Messages like
  [p2.mirror] Problems resolving provisioning plan.
  [p2.mirror] Unable to satisfy dependency from <my plugin> to bundle org.eventb.ui 0.0.0.
are normal, it just indicates that the repository does not contain core bundles.
 
From this point, continue the same as with 'site.xml', from 'test locally' on.
 
=== Categorizing a build repository ===
 
Build repositories are not categorized by default. To assign a built feature a category, we have to use the Category Publisher:
# copy the build repository somewhere, we'll call that somewhere $REPO (it ensures you can relaunch categorization if something goes wrong, without rebuilding your feature)
# write a category file
# run the Category Publisher
 
To make things concrete, here are sample files for categorizing the B2LaTeX plug-in:
 
category.xml:
<?xml version="1.0" encoding="UTF-8"?>
<site>
  <feature id="ac.soton.eventb.latex.feature">
    <category name="Utilities"/>
  </feature>
  <category-def name="Utilities" label="Utilities"/>
</site>
 
catPub.sh:
JAVA_HOME=/usr/lib/jvm/java-6-sun/jre
ECLIPSE_HOME=/path/to/eclipse
REPO=/path/to/buildRepo/copy
CAT_FOLDER=/path/to/category/folder
$JAVA_HOME/bin/java \
        -jar $ECLIPSE_HOME/plugins/org.eclipse.equinox.launcher_*.jar \
        -application org.eclipse.equinox.p2.publisher.CategoryPublisher \
        -metadataRepository file:/$REPO \
        -categoryDefinition file:/$CAT_FOLDER/category.xml
 
== Remote test and publishing ==
 
* test locally, using org.rodinp.updateSite as local update site; in particular, check that other plug-ins on the update site are still listed
 
* upload the jars generated by the build as usual in your plugin's area on [http://sourceforge.net/apps/trac/sourceforge/wiki/Release%20files%20for%20download SourceForge FRS]


If you are using scripts to build your feature (that is, without a running eclipse interface), ensure that your build scripts produce a repository (like 'buildRepo').
* test remotely by uploading 'content.jar' and 'artifacts.jar' to /home/project-web/rodin-b-sharp/htdocs/test-updates on the rodin web space, and using 'http://rodin-b-sharp.sourceforge.net/test-updates' as remote update site (see #Remote test)
Then used the 'publishFeature.xml' ant script in org.rodinp.updateSite (modifying the 'featureRepo' property in the launch config) to update 'content.jar' and 'artifacts.jar'.
The rest is as above, from local test on.


== Remote test ==
Copy 'content.jar' and 'artifacts.jar' from your eclipse workspace to you user home directory (this just makes it easier to locate the file from the terminal command line since the user home directory is the default local directory in Terminal)
Copy 'content.jar' and 'artifacts.jar' from your eclipse workspace to you user home directory (this just makes it easier to locate the file from the terminal command line since the user home directory is the default local directory in Terminal)
Open the Terminal utility and enter the following commands replacing <sourceforgeusername> and <sourceforgepassword>:
Open the Terminal utility and enter the following commands replacing <sourceforgeusername> and <sourceforgepassword>:
Line 33: Line 84:
  Connecting to web.sourceforge.net...
  Connecting to web.sourceforge.net...
  <sourceforgeusername>,rodin-b-sharp@web.sourceforge.net's password: <sourceforgepassword>
  <sourceforgeusername>,rodin-b-sharp@web.sourceforge.net's password: <sourceforgepassword>
  sftp> cd htdocs
  sftp> cd htdocs/test-updates
sftp> cd test-updates
  sftp> ls -a
  sftp> ls -a
  .          ..        .htaccess
  .          ..        .htaccess
  sftp> put content.jar
  sftp> put content.jar
  sftp> put artifacts.jar
Uploading content.jar to /home/project-web/rodin-b-sharp/htdocs/test-updates/content.jar
content.jar                                                                                                                                            100%  82KB  82.3KB/s  00:01   
sftp> chmod 644 content.jar
Changing mode on /home/project-web/rodin-b-sharp/htdocs/test-updates/content.jar
  sftp> put artifacts.jar  
Uploading artifacts.jar to /home/project-web/rodin-b-sharp/htdocs/test-updates/artifacts.jar
artifacts.jar                                                                                                                                          100% 8975    8.8KB/s  00:00   
sftp> chmod 644 artifacts.jar
Changing mode on /home/project-web/rodin-b-sharp/htdocs/test-updates/artifacts.jar
 
As an alternative, you can run script 'upload.sh'
./upload.sh
Sourceforge username: <sourceforgeusername>
<sourceforgeusername>,rodin-b-sharp@web.sourceforge.net's password: <sourceforgepassword>
content.jar                                                                    100%  155KB 155.1KB/s  00:00   
artifacts.jar                                                                  100%  11KB  11.0KB/s  00:00 
 
You can then try this remote update site from a running Rodin platform.
To do this, just add the remote site to the list of available sites (which will look like below)
Rodin Remote Test Update Site - http://rodin-b-sharp.sourceforge.net/test-updates
and select it.
 
The .htaccess file redirects plugins/*.jar and features/*.jar requests to [http://sourceforge.net/apps/trac/sourceforge/wiki/Release%20files%20for%20download SourceForge FRS], thus using the archives that you have uploaded.<br>
 
'''Once the test is complete, please remove the jars:'''
sftp> rm *.jar
Removing /home/project-web/rodin-b-sharp/htdocs/test-updates/artifacts.jar
Removing /home/project-web/rodin-b-sharp/htdocs/test-updates/content.jar
 
'''Then to finally ''publish'' the updated main Rodin Update Site :'''
* commit 'content.jar' and 'artifacts.jar' to SVN (it will update the remote Rodin Update site)
* test using the standard Rodin Update Site (you may need to reload it)
 
== Removing installable units ==
In order to remove installable units (features/plugins) from the repository, an Ant script named 'removeFeature.xml' has been created.
 
# make sure your workspace copy of the plugin project 'org.rodinp.updateSite' is synchronised with the SVN repository.
# open 'removeFeature.xml' with the Ant editor.
# replace the token 'your_feature_id' (twice) with the id of the feature that you want to remove. At the same time, specify the version number (replace 'x.x.x.x') with the version number of the feature that you want to remove. If version number is left out, the latest version of the feature matched the declared id will be removed.
# replace tokens such as 'your_plugin_id', 'your_other_plugin_id' with the id of the plugins that you want to remove. Again, specify the version numbers of the plugins or leave it out.
# Run 'removeFeature.xml' as an Ant Build (right-click/ Run As / Ant Build)
# Refresh project 'org.rodinp.updateSite'.
# test locally, using org.rodinp.updateSite as local update site; in particular, check that other plug-ins on the update site are still listed
# test remotely by uploading 'content.jar' and 'artifacts.jar' to /home/project-web/rodin-b-sharp/htdocs/test-updates on the rodin web space, and using 'http://rodin-b-sharp.sourceforge.net/test-updates' as remote update site (see [[#Remote test]])
# commit 'content.jar' and 'artifacts.jar' to SVN: it actually updates the Rodin Update Site itself
# test using the standard Rodin Update Site (you may need to reload it)


Once the test is complete, please remove the jars ('rm' command).
''Tip 1'': If you want to remove all versions of the feature/plugins, just leave out the version number and keep running the Ant script until you see 'Unable to find: Installable Unit [...]' for all features/plugins that you specified


''Tip 2'': Do NOT upload 'removeFeature.xml' to SVN (this instruction will be outdated)




[[Category:Developer documentation|*Index]]
[[Category:Developer documentation|*Index]]
[[Category:Rodin Platform|*Index]]
[[Category:Rodin Platform|*Index]]

Latest revision as of 09:06, 27 May 2015

Since April 5th, 2012, the Rodin update site has the newer p2 format. From a release engineer point of view, the main change is that instead of uploading 'site.xml' to the rodin web space, you will just commit 'content.jar' and 'artifacts.jar' to SVN. This page explains how to generate these two files.

There are two different ways to update the main Rodin Update site :

  1. using the site.xml file to build an updated version of the p2 site (see Details_for_Uploading_Main_Rodin_Update_Site#Using_site.xml),
  2. using a script to update the p2 site from your feature repository (see Details_for_Uploading_Main_Rodin_Update_Site#Using_an_externally_built_feature).

If you're interested in internal details, you can take a look at How we set up the p2 update site on SourceForge.
There are some few rules to follow when providing contents to the main Rodin update site, please take a look at them.


Using site.xml

Even though 'site.xml' is no more present on the remote update site, it can be used locally to publish new features (or new versions of existing features).

  1. make sure your workspace copy of the plugin project org.rodinp.updateSite is synchronised with the SVN repository.
  2. open 'site.xml' with the Site Manifest Editor
  3. add your feature to the relevant category (no need to give artifact url)
  4. click 'Build': 'content.jar' and 'artifacts.jar' get updated, 'features' and 'plugins' directories are created (do NOT click 'Build All', it would overwrite the update site !)
  5. test locally, using org.rodinp.updateSite as local update site; in particular, check that other plug-ins on the update site are still listed
  6. upload the jars generated by the build as usual in your plugin's area on SourceForge FRS
  7. test remotely by uploading 'content.jar' and 'artifacts.jar' to /home/project-web/rodin-b-sharp/htdocs/test-updates on the rodin web space, and using 'http://rodin-b-sharp.sourceforge.net/test-updates' as remote update site (see #Remote test)
  8. commit 'content.jar' and 'artifacts.jar' to SVN: it actually updates the Rodin Update Site itself
  9. test using the standard Rodin Update Site (you may need to reload it)

So 'site.xml' is no more uploaded nor committed to SVN, it is really just there to help working with 'content.jar' and 'artifacts.jar'. In particular, if for some reason you want to commit it nevertheless, take care not to commit the post 'Build' version, as it mixes everything up.

Using an externally built feature

That's the scripted way to proceed. If you are using scripts to build your feature (that is, without a running eclipse interface):

  1. ensure that your build scripts produce a repository (like 'buildRepo')
  2. categorize the repository (see below)
  3. launch the 'publishFeature.xml' ant script in org.rodinp.updateSite on the categorized repository (modifying the 'featureRepo' property in the launch config) to update 'content.jar' and 'artifacts.jar'.

Messages like

  [p2.mirror] Problems resolving provisioning plan.
  [p2.mirror] Unable to satisfy dependency from <my plugin> to bundle org.eventb.ui 0.0.0.

are normal, it just indicates that the repository does not contain core bundles.

From this point, continue the same as with 'site.xml', from 'test locally' on.

Categorizing a build repository

Build repositories are not categorized by default. To assign a built feature a category, we have to use the Category Publisher:

  1. copy the build repository somewhere, we'll call that somewhere $REPO (it ensures you can relaunch categorization if something goes wrong, without rebuilding your feature)
  2. write a category file
  3. run the Category Publisher

To make things concrete, here are sample files for categorizing the B2LaTeX plug-in:

category.xml:

<?xml version="1.0" encoding="UTF-8"?> 
<site> 
  <feature id="ac.soton.eventb.latex.feature"> 
    <category name="Utilities"/> 
  </feature> 
  <category-def name="Utilities" label="Utilities"/> 
</site> 

catPub.sh:

JAVA_HOME=/usr/lib/jvm/java-6-sun/jre
ECLIPSE_HOME=/path/to/eclipse
REPO=/path/to/buildRepo/copy
CAT_FOLDER=/path/to/category/folder

$JAVA_HOME/bin/java \
       -jar $ECLIPSE_HOME/plugins/org.eclipse.equinox.launcher_*.jar \
       -application org.eclipse.equinox.p2.publisher.CategoryPublisher \
       -metadataRepository file:/$REPO \
       -categoryDefinition file:/$CAT_FOLDER/category.xml

Remote test and publishing

  • test locally, using org.rodinp.updateSite as local update site; in particular, check that other plug-ins on the update site are still listed
  • upload the jars generated by the build as usual in your plugin's area on SourceForge FRS

Copy 'content.jar' and 'artifacts.jar' from your eclipse workspace to you user home directory (this just makes it easier to locate the file from the terminal command line since the user home directory is the default local directory in Terminal) Open the Terminal utility and enter the following commands replacing <sourceforgeusername> and <sourceforgepassword>:

Last login: Tue May 17 21:22:29 on console
dhcp-152-78-95-201:~ <localusername>$ sftp <sourceforgeusername>,rodin-b-sharp@web.sourceforge.net
Connecting to web.sourceforge.net...
<sourceforgeusername>,rodin-b-sharp@web.sourceforge.net's password: <sourceforgepassword>
sftp> cd htdocs/test-updates
sftp> ls -a
.          ..         .htaccess
sftp> put content.jar 
Uploading content.jar to /home/project-web/rodin-b-sharp/htdocs/test-updates/content.jar
content.jar                                                                                                                                            100%   82KB  82.3KB/s   00:01    
sftp> chmod 644 content.jar 
Changing mode on /home/project-web/rodin-b-sharp/htdocs/test-updates/content.jar
sftp> put artifacts.jar 
Uploading artifacts.jar to /home/project-web/rodin-b-sharp/htdocs/test-updates/artifacts.jar
artifacts.jar                                                                                                                                          100% 8975     8.8KB/s   00:00    
sftp> chmod 644 artifacts.jar 
Changing mode on /home/project-web/rodin-b-sharp/htdocs/test-updates/artifacts.jar

As an alternative, you can run script 'upload.sh'

./upload.sh
Sourceforge username: <sourceforgeusername>
<sourceforgeusername>,rodin-b-sharp@web.sourceforge.net's password: <sourceforgepassword>
content.jar                                                                     100%  155KB 155.1KB/s   00:00    
artifacts.jar                                                                   100%   11KB  11.0KB/s   00:00  

You can then try this remote update site from a running Rodin platform. To do this, just add the remote site to the list of available sites (which will look like below)

Rodin Remote Test Update Site - http://rodin-b-sharp.sourceforge.net/test-updates

and select it.

The .htaccess file redirects plugins/*.jar and features/*.jar requests to SourceForge FRS, thus using the archives that you have uploaded.

Once the test is complete, please remove the jars:

sftp> rm *.jar
Removing /home/project-web/rodin-b-sharp/htdocs/test-updates/artifacts.jar
Removing /home/project-web/rodin-b-sharp/htdocs/test-updates/content.jar

Then to finally publish the updated main Rodin Update Site :

  • commit 'content.jar' and 'artifacts.jar' to SVN (it will update the remote Rodin Update site)
  • test using the standard Rodin Update Site (you may need to reload it)

Removing installable units

In order to remove installable units (features/plugins) from the repository, an Ant script named 'removeFeature.xml' has been created.

  1. make sure your workspace copy of the plugin project 'org.rodinp.updateSite' is synchronised with the SVN repository.
  2. open 'removeFeature.xml' with the Ant editor.
  3. replace the token 'your_feature_id' (twice) with the id of the feature that you want to remove. At the same time, specify the version number (replace 'x.x.x.x') with the version number of the feature that you want to remove. If version number is left out, the latest version of the feature matched the declared id will be removed.
  4. replace tokens such as 'your_plugin_id', 'your_other_plugin_id' with the id of the plugins that you want to remove. Again, specify the version numbers of the plugins or leave it out.
  5. Run 'removeFeature.xml' as an Ant Build (right-click/ Run As / Ant Build)
  6. Refresh project 'org.rodinp.updateSite'.
  7. test locally, using org.rodinp.updateSite as local update site; in particular, check that other plug-ins on the update site are still listed
  8. test remotely by uploading 'content.jar' and 'artifacts.jar' to /home/project-web/rodin-b-sharp/htdocs/test-updates on the rodin web space, and using 'http://rodin-b-sharp.sourceforge.net/test-updates' as remote update site (see #Remote test)
  9. commit 'content.jar' and 'artifacts.jar' to SVN: it actually updates the Rodin Update Site itself
  10. test using the standard Rodin Update Site (you may need to reload it)

Tip 1: If you want to remove all versions of the feature/plugins, just leave out the version number and keep running the Ant script until you see 'Unable to find: Installable Unit [...]' for all features/plugins that you specified

Tip 2: Do NOT upload 'removeFeature.xml' to SVN (this instruction will be outdated)