PTP uses Hudson for nightly and release builds. Nightly builds will start if a change in the Git repository is detected. Release builds must be manually started (currently).
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. The jobs are:
- ptp-photran-nightly and ptp-photran-release
- This job builds the Photran project and generates a zip file containing a p2 repository.
- ptp-nightly and ptp-release
- This job builds the PTP project and generates a zip file containing a p2 repository. The RDT server files and the proxy zip file is also generated.
- ptp-master-nightly and ptp-master-release
- This job aggregates the Photran and PTP projects together to produce the final repository.
These jobs are linked together so that they run in this order (from top to bottom). E.g. if the ptp-photran-nightly job runs, it will start ptp-nightly when completed, which will in turn start ptp-master-nightly.
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.
- ↑ 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:
- Obtain a copy of the
update_versionsscript from the
- Run the command "
sh update_versions ptp-version photran-version" where
ptp-versionis the new version number for PTP, and
photran-versionis the new version number for Photran, e.g.
sh update_versions 3.0.1 5.0.1
- The command will clone new copies of the photon, ptp, and ptp.master repos and update the versions appropriately
- When the command completes, change to
fix_ptp_versionsand check that the repos have be updated correctly.
- 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)
- Remove the
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.
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.
On completion, a successful build will be located in
M.N.S is the version number of the release, and
YYYYMMDDHHMM is the date and time stamp for the build. The build also updates the
/home/www/download.eclipse.org/tools/ptp/builds/M.N.S/index.html file to include the new build.
On completion, a successful build will be located in
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
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.xmlfile 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.xmlfile in the repo plugin (
- In the org.eclipse.ptp.master.git Git repository, add the new feature to the
category.xmlfile in the repository root.
- or should this be org.eclipse.ptp.master ? cloned from ssh://<userid>@git.eclipse.org/gitroot/ptp/org.eclipse.ptp.master
- See next section Simultaneous Release for how to add the feature to the simrel repository too.
For the Eclipse Simultaneous Release (e.g. Juno, Kepler, Luna) contribution of PTP, the features of PTP need to be added to the simrel repository. To do so, see Contributing to the Simrel Aggregation Build. In a 4.2.2 workbench, Check out the
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. 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 http://hudson.eclipse.org) or it can be started from the hudson page.
EPP Eclipse Packaging Project
Updates required for building the Parallel Package...