Skip to main content
Jump to: navigation, search

Papyrus/Papyrus Developer Guide/Release Process: Doc

Releng Project

The papyrus releng project is called : releng


It contains poms corresponding to each build:

  • main/pom.xml
  • main-tests/pom.xml
  • dev/pom.xml
  • extras/pom.xml (for Neon and previous versions)
  • extra-tests/pom.xml (for Neon and previous versions)
  • rcp/pom.xml

And the hudsonJobs folder contains the configuration for those build:

  • : That moves the repository folder at the root of the job, packages the result in a zip, and triggers the publishing of this zip as a nigtly.

And these scripts are common to all the builds:

  • server : (after each modification, the scripts in this directory must be copied into "/opt/public/modeling/mdt/papyrus" where they run : commit the script and run /opt/public/modeling/mdt/papyrus/
    • : script that enables download statistics on an update site
    • addDownloadStats-main.xsl : XSL transformation that enables download statistics on a "main" update site (it contains the list of significant plug-ins for the stats)
    • addDownloadStats-extra.xsl : XSL transformation that enables download statistics on a "extra" update site (it contains the list of significant plug-ins for the stats)
  • : script to add a child update site to a composite update site definition (calls addToComposite.xsl)
  • addToComposite.xsl : XSL transformation to add a child update site to a composite update site definition
  • : retrieves the configuration files for all the Papyrus Hudson jobs, and copies them into the hudsonJobs folder (configure a password-less ssh login to avoid having to type your password 10 times in a row). Run this script every time you make changes to the Hudson job configurations, in order to keep a versioned backup of these changes.
    • : a script that runs as a cron on to publish the latest nightlies (main, extra and tests). It runs and sends a mail if this script failed.
    • : the script that does the actual work for
    • : helper functions for the publishing scripts
    • : this is an interactive script that can be started by a Papyrus committer to publish a build into the Papyrus downloads and update site
    • : run this script from /opt/public/modeling/mdt/papyrus/ to update the scripts on the server after committing your changes

Release process

Papyrus Developer Guide/Release Process: How To

Automatic publishing to the downloads server

Nightly builds are published automatically to

This part is a bit tricky, as the build server ( and the download server are two separate servers, with different access rights. The download server can be accessed by all committers, but the Hudson jobs are launched by a Hudson user that does not have write access to the download server. Thus, publishing results is done in two parts:

  • the Hudson task gathers all results and sends a signal to the download server (basically, writing a signal file on the download server, with information on what to publish and where).

Build dependencies

The dependency appears in the pom.xml:


Finding dependencies

If you don't know where a particular plug-in or feature is located, the easiest way to find it is to search the Eclipse download area using "find" on For example, to look for "" :

find /home/data/httpd/ -name 'org.eclipse.emf.compare_*'

Publishing a build in the aggregator

The Eclipse simultaneous release train is built with the B3 aggregator. To be part of the aggregation, you must add your contribution to the aggregation model.

First, you need to install the B3 aggregator. Theoretically, you can edit the model with any text editor, but it is better to edit it with the B3 editor, which will check that your model is valid.

It is suggested that you install the B3 aggregator in a separate Eclipse, dedicated to releng activities. For the Luna and Mars simultaneous releases, you will need the B3 installations :

  • open "mdt-papyrus.b3aggrcon"
  • change the location on this line to point to the build you want to publish in the aggregator:
<repositories location="" description="Papyrus">
  • validate the build model :
    • open "simrel.b3aggr"
    • right-click on the root and choose Validate Aggregation
    • open the error log and see if everything went OK
  • commit your changes

contact information

The people responsible for the build should be listed as contacts in the build model:


What do you select in your files ?

The licence.html file should be selected for both binary and source builds. The source folder ("src/") should not be selected for the binary nor the source build.

Creating a composite update site

A composite update site contains child update sites that appear as if their contents were in the composite update site. It is a way to aggregate update sites without having to physically move all the plug-ins in the same "plugins" directory (and the features in the "features" directory).

To create a composite update site, add two files named compositeArtifacts.xml and compositeContent.xml at the root of the composite update site. Here is an example of the content of these files, for a composite update site that contains two children named "main" and "extra".

"p2.timestamp" is the Unix date in milliseconds, which must be udpated everytime you change the compositeArtifacts.xml or compositeContent.xml files. To obtain the right value, use the command:

date +%s000


<?xml version="1.0" encoding="UTF-8"?>
<repository name="Papyrus" type="org.eclipse.equinox.internal.p2.artifact.repository.CompositeArtifactRepository" version="1.0.0">
  <properties size="1">
    <property name="p2.timestamp" value="1327488131000"/>
  <children size="2">
    <child location="main"/>
    <child location="extra"/>


<?xml version="1.0" encoding="UTF-8"?>
<repository name="Papyrus" type="org.eclipse.equinox.internal.p2.metadata.repository.CompositeMetadataRepository" version="1.0.0">
  <properties size="1">
    <property name="p2.timestamp" value="1327488131000"/>
  <children size="2">
    <child location="main"/>
    <child location="extra"/>

The update site directory looks like this:


You can also make a composite child point to a different location. This is useful for moving update sites to transparently (see bug 349141).

For example:

<child location=""/> 

see also [1]

Papyrus update sites

The Papyrus update sites are under:

corresponding to this directory mounted on


The Papyrus update sites follow this layout:

releases (folder)
  helios (composite update site)
  indigo (composite update site)
    0.8.0 (update site)
    0.8.1 (update site)
  juno (composite update site)
    0.9.0 (composite update site)
      main (update site)
      extra (update site)
  0.8 (composite update site)
    SR2_RC1 (update site)
    SR2_RC2 (update site)
  0.9 (composite update site)
    M4 (composite update site)
    M5 (composite update site)
      main (update site)
      extra (update site)
  indigo (composite update site)
  juno (composite update site)
    main (update site)
    extra (update site)

Papyrus downloads

The Papyrus download page is:

This page is generated from downloads-common.php and downloads-scripts.php that are defined in the folder "/www/modeling/mdt/papyrus/downloads/" on CVS "".

Download statistics

The statistics are enabled on repositories that are published with This script calls, and it uses:

  • addDownloadStats-main.xsl for statistics on the main update site
  • addDownloadStats-extra.xsl for statistics on the extra update site

These XSL transformations add the property "p2.statsURI" to the update site metadata, and add a "download.stats" property on a few bundles that are significant for the project's statistics.

The statistics can then be seen on the Eclipse portal (see the documentation below)


Archiving old builds

The server only has so much space. So, the webmaster set a 2 GiB quota per project.

To stay under this limit, old builds should be either deleted or moved to

This must be done in accordance to the Papyrus retention policy. TODO: Papyrus should define a retention policy, and link to it in the portal.

See :

Eclipse simultaneous release plan

The page for each project's simultaneous release is usually:<release_name>/Simultaneous_Release_Plan

For example:


It contains the date each milestone is expected to be available, depending on whether the project has a +0, +1, +2 or +3 offset. Each project determines its offset depending on its dependencies : if it depends on +2 projects, then it should be +3. And if it depends on +3 projects, then it is still +3, because there is no +4 offset. In this case, communication between the projects is essential, to make sure that each build depends on the right version of its dependencies.

Each project in the simultaneous release should also respect:

  • API Freeze at M6 : no API changes should occur after M6
  • UI freeze at M6 : no major UI changes should occur after M6, in order to give Babel translators enough time to translate everything before the release
  • Feature Freeze at M7 : no new features should be developped after M7 (only bug fixes, documentation and releng changes should be committed for the release candidates)

Final Daze

As the time for the big release in june each year approaches, each project in the simultaneous release must keep informed about the plan for the release, and perform some actions at the right time to ensure the release goes smoothly (such as cleaning up, archiving, publishing the documentation, putting the release bits in the right place for mirroring, etc.).

This is documented in a page conventionally named:<release_name>/Final_Daze

for example:

It is also very important to read the cross-project-issues-dev mailing list regularly, to stay informed about everything concerning the simultaneous release.

Entering the simultaneous release train

Quick steps

Back to the top