STP Build Process and Procedures
This page is to collect general information and references about the STP build process and procedures. STP build process is refactored from WTP Build Process and Procedures, so you can also use the information found in those pages.
Thanks, Naci Dai, 29 April 2006
STP builds are currently running on a trial basis. There is no build schedule.
However, a typical weekly I-Build needs contributions to be released by EOD Wednesday's, we smoke test that build on Thursday's, and to declare it by Friday's at noon (eastern time).
Running Build Locally
Running a local build is quite straighforward, but needs some build-mastery. Before you attempt a local build, make sure that you have some of the build prerequisites setup on your machine:
- CVS - you will need a cvs client installed on your machine. Build needs to find it on your path. You can get it from [].
- zip/unzip - If you are using Windows, you will need the commandline zip/unzip. You can getit from []
To run the build, first checkout the build module from STP CVS.
cvs -d :pserver:email@example.com:/cvsroot/stp co build
Then, go into the folder build/cruise. Review the contents of the build.properties file. Edit them to match your choices. baseos is linux, macos, win32, etc. basews is gtk, win32, basearch is ppc, x86. You can find all supported configuration from eclipse base platform. Set the build.home to where you want all workdirs and steup files to be copied. And, you should have an internet connection before you start the build.
build.home=/shared/stp mapCvsRoot=:ext:firstname.lastname@example.org:/cvsroot/stp baseos=linux basews=gtk basearch=ppc
Once you have the properties set, just run ant with the build file named build.xml and watch it build one components after the other, test, create a website etc.
Be warned that unless you are the build master, you will see two failures during the build: First it will not be able to send a notice email, and second it will not be able to upload your build to the downloads area. These failues are normal if you are doing a local build.
The platform's releng tool should be used to "release" projects to the map files. The release is done with:
- commiting changes to CVS.
- tagging the module (plugin or feature) using the versining standard described below
- release the tagged verion by modifying the corresponding map file in build/releng/maps
The releng module is monitored by cruisecontrol. Whenever there is change a new build will automatically trigger. Once teh build is complete, it is automatically delievered to: .
When a build is declared (i.e. becomes official), it is moved to . The declaration process is manual.
As projects are versioned, please use the "standard" format, in UTC time, following vYYYYMMDDHHMM. This is important as these cvs tags become the qualifier field of the plugin's version.
Note: do NOT use underscores in the CVS version, as there are some issues with Eclispe tooling when it finds an underscore in a plugin or version qualifier, see .
How to watch the builds
Do you enjoy watching screens of console logs fly by as much as I? Waiting for that joyous final result? Well then you too can do that with the following information.
We are currently doing our builds on build.eclipse.org. Any committer can logon to that server using their committer ID and password. I use something like
Once there the main work we do is in /shared/webtools/. If you want to "watch" the console log while the compiiler and ant files are running, you can use
tail -f /shared/stp/build/cruise/cruise.out -n200
to watch the last part of the main log (during compile, etc.). This is the fastest way to find out if the build failed. Once it does fail, there's some diagnostic messages that might be informative in the last 20 or 50 lines. (Do be careful, though, the build always says "Build Successful" as its very very last message, and that message just means all the ant scripts were any to completely execute (not that they did so successfully).
During tests, you can watch test results console at,
tail -f /shared/stp/test-stp-I/results/consolelogs/stptestlog.txt -n200
Background and Further Reading References
We in STP following the basic process and recommendations for versioning as the base Eclipse platform. Plugin Versioning
Very helpful guide to builds and automatic testing. Build and Test Automation for plug-ins and features
Good step-by-step on how to do updates. How To Keep Up To Date
We base our builds on the Eclipse platform's "basebuilder". Platform-releng
Our basic server configuration and cruise control triggers is handled by the STP project build/cruise directory.
And ... never forget Eclipse Help ... search for things related to update manager, PDE, features, site.xml, etc.