|Every night, 19:30 EDT||M4 prep build|
|Friday, June 26th, 08:30 EDT||Final build towards M4 - we'll need a go on this build|
Submitting For the Build
Checking in code: The checkin comment should at a minimum include "bug #", and preferably be of the form "bug # summary"
For the build:
Tool: Teams should use the "Eclipse Releng Tools" to update their releng project for each build. The releng tools can be installed from the update sites already included in 3.5.
Tags: tags should be of the form v<date>, so v20081120 or v20081120-1300
- check out your team releng project from e4/releng
- use the psf files to check out your core plugins, tests, and examples
- Run Team>Release from the context menu:
- Select your team's releng project, like org.eclipse.e4.ui.releng.
- Select the projects you want to release from your map file.
- You can review the changed projects in this pane. Make sure 'Generate Build Notes' is selected.
- Copy out the build note changes so you can send an email to firstname.lastname@example.org,
with a subject that starts with [releng]. You don not have to select a build
notes file to continue.
- Enter the release tag for you build. This would normally be the build time and date with a v in front, v20090101-1930
- You can review the changes to your map file here, or simply continue.
- Commit the changes so they will be picked up by the I-build
Versioning Plugins: Teams should try and follow the standard versioning rules posted at Version_Numbering. If you need to copy over an existing eclipse project to make changes, please increment the minor number by 100. i.e. 3.5.0 becomes 3.105.0. When you need to break API, then update the major number. i.e. 3.105.0 becomes 4.0.0
We run our builds on build.eclipse.org (a ppc linux machine) with a local userid, e4Build.
The main build project is in
e4/releng/org.eclipse.e4.builder. It contains the
masterBuild.sh script that can be modified to run a test build or a real build (tagged and uploaded to download.eclipse.org). It also contains the PDE build directory,
e4/releng/org.eclipse.e4.builder/builder/general, that builds our master feature. Our PDE build directory also contains modified code/XML to support using p2 to run our automated tests.
There are a number of directories that need to be available to run a build.
- /opt/public/common: the java installs can be appropriate for your architecture.
apache-ant-1.7.0/ ibm-java2-ppc-50@ ibm-java-jdk-ppc-60@ flex_sdk_18.104.22.16894_mpl/ ibm-java2-ppc-50-old@ ibm-java-ppc-60@ ibm-java2-142@ ibm-java2-ppc64-50@
To run the tests, we need a virtual X server on :8:
Xvfb :8 -screen 0 1280x1024x24 -auth auth.cfg metacity --display=:8.0 --replace --sm-disable
Where auth.cfg contains at least:
The build is currently controlled from the
masterBuild.sh script. There are a number of dependencies that make this a linux only build, and the machine has to be set up the same way as build.eclipse.org. This section will capture the requirements/process so that all of the needed steps are executed. See bug releng - Run a build from any platform for any discussions about this section.
We have a set of variables that are needed in order to make the system go.
The base directory that contains all build related files except the JREs.
The branch to check out the releng project (this contains subprojects that contain all our maps). Default is HEAD.
The CVS root used to check out the releng project. For anonymous test builds, it is
Build architecture, currently x86 or ppc.
The directory that contains the eclipse install used to build (by default we use the eclipse basebuilder), and usually
Points to the
Build date in the format YYYYMMDD, ex: 20090625
Build time in the 24 hour clock format HHMM, ex: 1930
Controls if we tag the map files after we check out our releng project.
Controls if we should upload the finished build. Currently this is the form of an SCP destination directory.
The tag that determines which base builder we use for the build.
The ID of the eclipse build we use as a target platform. With the changes to use a zipped repo for the eclipse SDK, this ID is only used to generate URLs on the download page. It should potentially be used to collect the correct p2 repo for the eclipse/equinox SDK.
The java that is used to launch JVMs from the masterBuild.sh script.
The date and time together: 20090625-1930
The directory to build in, by default
A directory that contains "target platforms" to work against. It contains a zip download cache, any eclipse target platforms, an untransformed repo directory (a directory with zipped repos to use in the build), and the runnable repo generated by the build.
The directory for the current build,
The directory used for running the automated tests.
The directory for the build results. This will contain the index.html, compile logs, p2 repo, platform zips, etc. Defaults to
The root directory for the eclipse install that will run the build. By default we use the eclipse basebuilder.
The resources, ui, and swt teams now have plugins in their team area in the e4 project. Our project is under :pserver:email@example.com:/cvsroot/eclipse
The resources CVS structure is:
The org.eclipse.e4.resources.releng contains the map files for building as well as Team Project Sets that should be used for checking out the projects to be worked on.
Resources currently has 4 features. 2 feature patches for the plugins (one for rcp, one for platform), a feature that contains the 2 patches, and a test feature for the tests.
Resources can currently update a 3.5 SDK I build and run.
The UI CVS structure is:
The org.eclipse.e4.ui.releng contains the map files for building as well as Team Project Sets that should be used for checking out the projects to be worked on.
UI currently has one main feature for the modelled workbench and one feature for the demos. The build master feature, org.eclipse.e4.master, is also in UI for now.
UI currently requires EMF 2.4.1 or 2.5.0 in installed on 3.5 in order to run. They can be installed from the update site included with the I builds.
The SWT CVS structure is:
The org.eclipse.e4.swt.releng contains the map files for building as well as Team Project Sets that should be used for checking out the projects to be worked on.
SWT has 2 features, one for the ActionScript tools and another for the ActionScript tests.
To update to the ActionScript tools you must first download and install the Open Source Flex SDK.
Setup Flex environment:
- Download and install the Adobe Open Source Flex SDK (available from http://opensource.adobe.com). NOTE: The path where you install the Flex SDK must contain no spaces. This is due to a bug in FCSH.
- update your eclipse.ini file and add another line at the end, -Dflex.sdk=<your path to the installed sdk>
Then you can update to the ActionScript tools. To work on the tools themselves, you must also set the FLEX_SDK classpath variable in Window>Preferences>Java>Build Path>Classpath Variables to point to the sdk location.
To work on org.eclipse.swt, org.eclipse.swt.e4.jcl, org.eclipse.swt.e4.examples, and org.eclipse.swt.examples you need to create a Linked Resource variable, WORKSPACE, that points to your current workspace root, from Window>Preferences>General>Workspace>Linked Resources. Also if .classpath_flex exists it must be copied to the .classpath entry.