Skip to main content

Notice: This Wiki is now read only and edits are no longer possible. Please see: for the plan.

Jump to: navigation, search

PTP/release engineering

Revision as of 10:31, 10 November 2014 by Unnamed Poltroon (Talk) (Simultaneous Release)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)


PTP uses Hudson for nightly and release builds.

In order to modify the build configuration, you need to be an authorized user. Please contact Greg, Beth, or Vivian if you need this access.

There are three Hudson jobs associated with each build[1], and there are three main types of build: nightly, release, and maint. The jobs for each build type are linked together so that they run the order shown (from top to bottom). E.g. if the ptp-nightly-photran job runs, it will start ptp-nightly-repo if completed successfully, which will in turn start ptp-nightly-packages.

All the jobs use Maven to run the build. Maven requires a pom.xml file in each package (plugin or feature) as well as a pom.xml at the top of each project tree. The version numbers of the pom.xml files must be kept in sync with their corresponding feature and plugin version numbers.


These are builds of the master branch, and are pre-release builds for the next PTP release. These builds are started automatically when the repository is updated by committing a change.

This job builds the Photran project and generates a zip file and a p2 repository. The final repository location is
This job builds the PTP project and combines it with Photran to generates a zip file containing the master p2 repository. The RDT server files and the sdm zip files are also generated. The final build location is currently
This job builds the PTP and SysMon packages using the repository generated in the ptp-nightly-repo build. The packages are located in also.


These are builds of the current PTP release. These builds can only be started manually.

This job builds the Photran repository. The final repository location is
This job builds the PTP master repository. The final build location is
This job builds the PTP and SysMon packages. (This is not the parallel package on the Eclipse downloads page, but our own versions of it created at every build, for our own use.)


These are builds of the previous PTP release. These builds can only be started manually.

This job builds the Photran repository. The final repository location is
This job builds the PTP repository and RDT zip files. The final build location is
This job builds the PTP master repository and copies the RDT files to the final location.

  1. This is required because the Hudson Git plugin does not support building from multiple repositories.


Prior to a new release, the version numbers of various features/plugins must be updated to reflect the version of the build. In general, the version numbers of plugins not listed here should only be changed if the plugin has been modified.

There is now a script that will update the version numbers appropriately as follows:

  1. Obtain a copy of the update_versions script from the org.eclipse.ptp.master.git repository.
  2. Run the command "sh update_versions user ptp-version photran-version [branch]" where user is a user with write access to the Git repo, ptp-version is the new version number for PTP, photran-version is the new version number for Photran, and branch is the branch to update. e.g.
    • sh update_versions user 3.0.1 5.0.1 ptp_7_0
    • The command will clone new copies of the photon, ptp, and ptp.master repos and update the versions appropriately
  3. When the command completes, change to fix_ptp_versions and check that the repos have be updated correctly.
  4. Commit and push the changes in each repo in turn using the commands:
    (cd org.eclipse.photran && git commit -m "Update PTP & Photran versions" && git push)
    (cd org.eclipse.ptp && git commit -m "Update PTP & Photran versions" && git push)
    (cd org.eclipse.ptp.master && git commit -m "Update PTP & Photran versions" && git push)
  5. Remove the fix_ptp_versions directory

The script should update the version number in the feature.xml for every feature and the pom.xml for every package. There are also a number of plugins that will have their plugin manifest files updated. The main pom.xml files in each repo will also be updated.

Build results

The nightly and release builds currently put their results in different locations. The results from each intermediate build step for all the hudson jobs are always available from the hudson build artifacts.

Release builds

On completion, a successful build will be located in /home/www/ The contents of this directory will need to be manually moved to the release location for the final build.

Nightly builds

On completion, a successful build will be located in /home/www/

Modifying the build

Changing the dependency versions

The versions of components that are required for the build jobs is determined by the top level pom.xml in repo for that build. These versions would normally need to be changed when a new version of Eclipse, CDT, Orbit, etc. is required for a particular build (e.g. to build for a Service Release). The versions are specified by the entries in the <properties></properties> section of the pom.xml.

Changing the RDT build versions

Whenever the versions of components are updated, the RDT build script also needs to be updated to ensure that the correct versions are also picked up. These are specified in the org.eclipse.ptp.rdt.core.remotejars/build.xml file. Depending on what has changed in the pom.xml, the versions specified in this file may need to be updated. Note that some of these are the versions of plugins that are included in the component, not just the component itself. This will require the component to be unzipped to determine the new versions.

Adding a new plugin or feature

For both plugins and features:

  • Add entries in the <modules></modules> section of the pom.xml file in the root of the corresponding Git repository.
    • To access this file, check out the whole repository as a general project (e.g. from Git Repositories Perspective)

If a new feature is being added:

  • In the org.eclipse.ptp.git Git repository, add the new feature to the category.xml file in the repo plugin (org.eclipse.[ptp|photran].repo)
  • See next section Simultaneous Release for how to add the feature to the simrel repository too.

Simultaneous Release

For the Eclipse Simultaneous Release (e.g. Juno, Kepler, Luna, Mars) contribution of PTP, the new feature(s) of PTP need to be added to the simrel repository. Note that features cannot be in the Parallel Package unless they are in the Simultaneous Release repository. To do so, see Contributing to the Simrel Aggregation Build. In an Eclipse workbench, Check out the

  • project

and install the b3 Aggregator editor (see instructions at Contributing to the Simrel Aggregation Build. )

  • Note: ONLY add features to the repo using this editor. Do not add a feature simply by editing the ptp.b3aggrcon file.
    • Edit the simrel.b3aggr file with the "Aggregator Model Editor" - changing that file changes the ptp.b3aggrcon file.
      • add a child to the Mapped Repository under "Contribution: PTP" (New Child > Feature) and use the Properties View to update the info in the unnamed feature item that is added.

Be sure to Validate (see the instructions). For milestone builds, the location of the PTP build to be used in the repository aggregation can be edited in the ptp.b3aggrcon using a simple text editor, and committed. Any change to a file in this project kicks off another aggregation build (e.g. simrel.kepler.runaggregator on or it can be started from the hudson page.

EPP Eclipse Packaging Project

Updates required for building the Parallel Package...

  • If the feature is required for the parallel package

Back to the top