Difference between pages "D45 Scalability" and "Details for Uploading Main Rodin Update Site"

From Event-B
(Difference between pages)
Jump to navigationJump to search
imported>Tommy
 
imported>Nicolas
 
Line 1: Line 1:
−
= Overview =
+
Since April 5th, 2012, the Rodin update site has the newer p2 format.
−
* '''Improved Performance''' According to the refocus mentionned in the [[D45_General_Platform_Maintenance#Motivations| General Platform Maintenance]] chapter, much of the reworking efforts performed on the core plateform basically aimed to overcome Rodin scalability weaknesses, and the continuous need of seamless proving experience. The whole performance was enhanced by core implementation and user interface refactorings. Improvements made to the proving experience will be detailed in a separate chapter.
+
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.
−
* {{TODO}} An overview of the contribution about the design pattern management / Generic Instantiation (Thai Son Hoang)
+
If you're interested in internal details, you can take a look at [[How we set up the p2 update site on SourceForge]].
−
* '''Edition''' It appeard along DEPLOY, the models defined by pilots becoming industrial sized due to the level of complexity reached, that the edition became a central concern.  
 
−
:*The legacy structured editor based on a form edition specific achitecture reach its limits in responsivness and hence in usability when being constrained to display a huge amount of graphical elements.  
 
−
:*Camille textual editor had to tackle challenges related to ressources mapping and management for projects of industrial size mentionned above or even the design of extension capabilities, that became a major concern since the grammar could be extended with theories.
 
  
−
= Motivations =
+
== Using site.xml ==
  
−
== Improved Performance ==
+
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).
−
It appeared that the various DEPLOY partners encountered several major issues while editing large models. Some were related to the core code of the Rodin platform, causing crashes, loss of data, corruption in models. Some other were related to the UI causing platform hanging, and sometimes leading to its freezing which required sometimes to kill the Rodin process, thus also leading to potential loss of data and corruption in models. Hence, it appeared necessary to solve such issues before the end of DEPLOY.
 
  
−
== Design Pattern Management / Generic Instantiation  ==
+
# make sure your workspace copy of the plugin project org.rodinp.updateSite is synchronised with the SVN repository.
−
{{TODO}} ''To be completed by Thai Son Hoang''
+
# open 'site.xml' with the Site Manifest Editor
−
== Edition ==
+
# add your feature to the relevant category (no need to give artifact url)
−
As said, from the growing size of complexity reached in models inducing a growing of their physical size lead the platform to its limits. Two major bugs were faced when developing such models.
+
# 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 !)
 +
# 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]
 +
# 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)
  
−
= Choices / Decisions =
+
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.
−
== Improved Performance ==
 
−
SYSTEREL lead a two phase investigation to have a better idea of the work to be done. Each phase being followed by some refactoring of the code. Out of the early investigation, a cause and effect relationship has been found between perfomance loss and the various reported bugs, such as "platform hanging" bugs or even "no more handle" bugs related to the high consumption of graphical elements on Windows platforms. Indeed, it appeared that solving the performance issues sometimes solved induced bugs as well which made the scalability improvement tasks emcompass the maintenance goals.<br>
 
−
Later, a deeper investigation was performed, to indentify and tackle the remaining performance issues. Profiling and code review were the two techniques used. The profiling strategy allowed to get a better localisation of the performance loss in both UI and core code while the code review helped to understand the intrinsic misuses or drawbacks of particular components and/or architectures.
 
−
A good example, was the Event-B built-in editor based on form editors with a high use of greedy graphical components. Such architecture appeard to be weak when it was needed to display industrial size models. This affected the modelling experience with some long, and really annoying to the user, reaction lags. To solve such issue, it has been chosen to refactor the editors using a textual representation which was a light-weight graphical alternative to lower the number of needed components.
 
  
−
== Design Pattern Management / Generic Instantiation  ==
+
== Externally built feature ==
−
{{TODO}} ''To be completed by Thai Son Hoang''
 
−
== Edition ==
 
  
 +
That's the harder 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.
  
−
* About the Text Editor {{TODO}} Ingo Weigelt
+
From this point, continue the same as with 'site.xml', from 'test locally' on.
  
−
= Available Documentation =
+
=== Categorizing a build repository ===
−
* {{TODO}} Links for Improved Performance
 
−
* {{TODO}} Links for Design Pattern Management / Generic Instantiation
 
−
* {{TODO}} Links for Edition
 
  
−
= Status =
+
Build repositories are not categorized by default. To assign a built feature a category, we have to use the Category Publisher:
−
== Improved Performance ==
+
# 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)
−
The refactoring made on both core code and UI code allowed to gain up to 25 times speed-up on the UI, and almost a 2 times speed-up in the core code, making the platform usable in an industrial sized context.<br>
+
# write a category file
 +
# run the Category Publisher
  
−
== Design Pattern Management / Generic Instantiation  ==
+
To make things concrete, here are sample files for categorizing the B2LaTeX plug-in:
−
{{TODO}} ''To be completed by Thai Son Hoang''
 
−
== Edition ==
 
−
{{TODO}} ''To be completed by Thomas Muller, Ingo Weigelt''
 
  
 +
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>
  
−
= References =
+
catPub.sh:
−
<references/>
+
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
  
−
[[Category:D45 Deliverable]]
+
== 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)
 +
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
 +
sftp> cd 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> 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   
 +
 
 +
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
 +
 +
 
 +
 
 +
 
 +
[[Category:Developer documentation|*Index]]
 +
[[Category:Rodin Platform|*Index]]

Revision as of 16:24, 5 April 2012

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. If you're interested in internal details, you can take a look at How we set up the p2 update site on SourceForge.

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.

Externally built feature

That's the harder 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

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
sftp> cd 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> 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

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
Retrieved from ‘https://wiki.event-b.org/index.php?title=D45_Scalability&oldid=3619’