Jump to: navigation, search

Difference between revisions of "WTP Build Process and Procedures"

(Managing builds for multiple WTP build streams)
(Removing all content from page)
 
(34 intermediate revisions by 6 users not shown)
Line 1: Line 1:
This page is to collect general information and references about the WTP build process and procedures. The idea is that any WTP committer can update it, pretty much "on the fly" or "as you go", or "as needed", so that there will often be a bit of a disorganized, stream of consciousness flavor to it. Hopefully, occasionally, some kind-hearted committer will stop and organize all the miscellaneous notes and tips and references that are provided, into fun-to-read treasure that you  just can't put down.
 
  
Note: since only committers can edit these pages, if anyone from the community has contributions or suggestions for additions, please open a [[https://bugs.eclipse.org/bugs/enter_bug.cgi?product=Web%20Tools;component=releng feature request]] on our releng component.
 
 
Thanks, [[User:David williams|David Williams]] 01:42, 2 February 2006 (EST)
 
 
== Build Schedules ==
 
 
As of February 1, 2006
 
 
Our WTP 1.0.1 contributions are due by EOD on Monday's, we smoke test that build on Tuesday's, and plan to declare it by Wednesday's at noon (eastern time).
 
 
Our WTP 1.5 contributions are due by EOD Wednesday's, we smoke test that build on Thursday's, and plan to declare it by Friday's at noon (eastern time).
 
 
 
== Build mechanics ==
 
 
The platform's releng tool should be used to "release" projects to the map files.
 
Be sure to have the appropriate branch of releng project (which has the map files)
 
loaded in your workspace.
 
R1_0_maintenance for 1.0.x builds, and HEAD for 1.5 builds.
 
 
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 [[https://bugs.eclipse.org/bugs/show_bug.cgi?id=89428 89428]].
 
 
== 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 <b>build.eclipse.org</b>. Any committer can logon to that server
 
using their committer ID and password. I use something like
 
 
  ssh david_williams@build.eclipse.org
 
 
Once there the main work we do is in <b>/shared/webtools/</b>. If you want to "watch" the console log while the compiiler and ant files are running, you can use
 
 
    tail -F /shared/webtools/releng.control/out.txt -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/webtools/test-wtp-S/results/consolelogs/wtptestlog.txt -n200
 
 
 
In fact, I do this so much, I define these aliases in my .bash_proflie
 
 
    alias tailout='tail -F /shared/webtools/releng.control/out.txt -n200'
 
    alias tailtest-i='tail -F /shared/webtools/test-wtp-I/results/consolelogs/wtptestlog.txt -n200'
 
    alias tailtest-m='tail -F /shared/webtools/test-wtp-M/results/consolelogs/wtptestlog.txt -n200'
 
    alias tailtest-r='tail -F /shared/webtools/test-wtp-R/results/consolelogs/wtptestlog.txt -n200'
 
    alias tailtest-s='tail -F /shared/webtools/test-wtp-S/results/consolelogs/wtptestlog.txt -n200'
 
 
Here the handy thing to watch for is if a test doesn't seem to make any progress at all, after 10-20 minutes.
 
That's a sure sign of a hang. And, here's how to get some diagnotic information on Linux.
 
First, "break out" of the tail program with ctrl-c. Then get a list of processes that are running by using
 
 
    ps -ef | grep java
 
 
Usually, torwards the end, you'll see a task that mentions, in the long (wrapped) command line, a recognizable JUnit suite. For that process, looking toward the left of the long (wrapped) line, get its process ID ... usually 4 or 5 digits. Then (almost there!) type "kill -3 <process-id>". I forget exactly what the '-3' means to Unix, but to Java, it means to take a dump of current data and thread states, You'll see a few messages to the console that a java dump wsa greated. That's the file that's handy to attach to a bugzills. (use sftp copy, if you do not have handier tools). That file is usually located in the /eclipse directory in use during the test.   
 
 
Feel free to edit this document with further tips (or, improve the directions above is I left out some steps, or, you've noticed things are slightly different than written here.
 
 
== Chronological Notes ==
 
 
This section is just to make quick notes about changes to our build files/scripts that others might find intersting.
 
 
=== Update prereqs to include official Eclipse M5 ===
 
<pre>
 
/downloads/drops/S-3.2M5-200602171115/
 
eclipse-SDK-3.2M5-win32.zip
 
eclipse-SDK-3.2M5-linux-gtk.tar.gz
 
eclipse-SDK-3.2M5-linux-gtk-ppc.tar.gz
 
eclipse-test-framework-3.2M5.zip
 
</pre>
 
There was an "odd" note when I downloaded the PPC version ...
 
<pre>
 
Eclipse fails to create a lock file with reason "No locks available."  To launch eclipse you must disable file
 
locking using the osgi.locking property. For example, you could launch eclipse as follows:
 
 
"eclipse -vmargs -Dosgi.locking=none".
 
</pre>
 
 
Thus, we *might* have to -Dosgi.locking=none on our PPC machine when we move to this M5 version of the base builder.
 
 
-- [[User:David williams|David williams]] 18:04, 21 February 2006 (EST)
 
 
 
 
=== 5/23/2006 Changes to build machine and CruiseControl ===
 
 
I've moved the
 
    /releng.builder/tools/cruise
 
stuff to another cvs project ... and called it
 
    /releng.control
 
 
The idea is that anything that is "machine specific" or "cruise control" specific  we can put in releng.control,  and have it under its own
 
versioning/update rules.  We'll attempt to keep the CVS version in synch with the eclipse.org PPC machine we use,
 
but other machines can be kept in "parallel" files, e.g. see
 
cruise-lomboz.properties
 
and rename them when deployed.
 
 
One implication (by design) is that "releng.builder" isn't downloaded and checked automatically by CruiseControl, in other words,
 
changes in it won't trigger a build. Not sure what is still used in "releng.builder", but know some things are, such as API checkers.
 
So, these API checkers will have to be downloaded or triggered by some other means (as has been our direction for a while).
 
 
Similar tor the "whatisfixed" tools .. I've turned it "off" by default ... it takes almost as long as the build itself!
 
So, we don't want to run it each build. Naci will be working on how to execute those separately against a
 
specific, declared build.
 
 
 
I've updated to cruise control 2.5 (they fixed that memory leak that was causing me to have to restart it every day or two).
 
(initially the 2.5 version was "crashing" frequently, but I think related to VM version, and seems to be running well now,
 
well ... for at least for 24 hours :)
 
 
I got the status is working again ... see
 
http://build.eclipse.org:7777/cruisecontrol/
 
 
 
[[User:David williams.us.ibm.com|David williams.us.ibm.com]] 21:02, 23 May 2006 (EDT)
 
 
=== drop/drivers moved to arhives/drops/drivers ===
 
 
To avoid mirroring our relatively temporary "drivers" directory, I've completed the move off
 
...webtools/downloads/drivers
 
to
 
/home/data/httpd/archive.eclipse.org/webtools/downloads/drivers
 
 
[[User:David williams.us.ibm.com|David williams.us.ibm.com]] 01:27, 27 May 2006 (EDT)
 
 
=== post 1.5 cleanup of drop site to archives site ===
 
 
For reference:
 
 
Pre-1.5 milestones and some old releases have been moved to
 
http://archive.eclipse.org/webtools/downloads/
 
 
Or, if you are navigating there directly, see
 
/home/data/httpd/archive.eclipse.org/webtools/downloads/drops
 
 
I've also moved the 0.7 translations there, see
 
/home/data/httpd/archive.eclipse.org/webtools/downloads/translations/
 
 
And, recall, we have some old, non-released pre-req drivers at
 
/home/data/httpd/archive.eclipse.org/webtools/downloads/drivers
 
 
These hopefully never have to be accessed, but, at the moment, if you do need one, the download
 
pages you'll find on the archive site are not quite operational.... their "links" still point to the "downloads"
 
area, instead of the "archived" area. But, the files are still there, so, for now, if you need one, you'll have to
 
get it via FTP, or, "manually" edit the URL to go to the archive area to download the zip file.
 
 
When some knowledgeable script experts have time, we may fix up the download pages, or,
 
we may simply make available in "directory list" form.
 
 
=== Managing builds for multiple WTP build streams ===
 
 
Following the 1.5 release, we started building WTP for 1.0, 1.5 and 2.0 streams concurrently. This required some modififications:
 
 
First, we added a property named "buildBranch" to the ant scripts in releng.wtpbuilder.  The value of the buildBranch is provided by the parent script that triggers the build.  Automated builds are triggered by cruisecontrol, so we also organized cruise projects by build type (i.e. R, S, I, N) and build branch (e.g. R1.0, R1.5, R2.0).
 
 
Second, the download areas for declared builds, committers and archives have been re-organized.  Previosly, all builds were kept under the same folder (e.g. webtools/downloads/drops).  Now there is a seperate folder for each build branch under drops.  It goes like
 
  drops/
 
    + R1.5
 
    |  ...
 
    + R1.0/
 
    |  + R-1.0.2...
 
    |  + I-I200607081130...
 
    + R1.5
 
    |  ...
 
    + R2.0
 
    |  ...
 
   
 
The translations are still left in the same place in the archives area.
 
 
We also updated the declare script in committers area.  Previosly the script required only one parameter, the full build stamp (e.g. ./declare.sh I-I200607130237-200607130237 ).  Now, we provide two parameters to this build script, the build branch and the build name as usual (e.g. ./declare.sh R2.0 I-I200607130237-200607130237)
 
 
== Build Schedules ==
 
 
As of February 1, 2006
 
 
Our WTP 1.0.1 contributions are due by EOD on Monday's, we smoke test that build on Tuesday's, and plan to declare it by Wednesday's at noon (eastern time).
 
 
Our WTP 1.5 contributions are due by EOD Wednesday's, we smoke test that build on Thursday's, and plan to declare it by Friday's at noon (eastern time).
 
 
 
== Build mechanics ==
 
 
The platform's releng tool should be used to "release" projects to the map files.
 
Be sure to have the appropriate branch of releng project (which has the map files)
 
loaded in your workspace.
 
R1_0_maintenance for 1.0.x builds, and HEAD for 1.5 builds.
 
 
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 [[https://bugs.eclipse.org/bugs/show_bug.cgi?id=89428 89428]].
 
 
== 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 <b>build.eclipse.org</b>. Any committer can logon to that server
 
using their committer ID and password. I use something like
 
 
  ssh david_williams@build.eclipse.org
 
 
Once there the main work we do is in <b>/shared/webtools/</b>. If you want to "watch" the console log while the compiiler and ant files are running, you can use
 
 
    tail -F /shared/webtools/releng.control/out.txt -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/webtools/test-wtp-S/results/consolelogs/wtptestlog.txt -n200
 
 
 
In fact, I do this so much, I define these aliases in my .bash_proflie
 
 
    alias tailout='tail -F /shared/webtools/releng.control/out.txt -n200'
 
    alias tailtest-i='tail -F /shared/webtools/test-wtp-I/results/consolelogs/wtptestlog.txt -n200'
 
    alias tailtest-m='tail -F /shared/webtools/test-wtp-M/results/consolelogs/wtptestlog.txt -n200'
 
    alias tailtest-r='tail -F /shared/webtools/test-wtp-R/results/consolelogs/wtptestlog.txt -n200'
 
    alias tailtest-s='tail -F /shared/webtools/test-wtp-S/results/consolelogs/wtptestlog.txt -n200'
 
 
Here the handy thing to watch for is if a test doesn't seem to make any progress at all, after 10-20 minutes.
 
That's a sure sign of a hang. And, here's how to get some diagnotic information on Linux.
 
First, "break out" of the tail program with ctrl-c. Then get a list of processes that are running by using
 
 
    ps -ef | grep java
 
 
Usually, torwards the end, you'll see a task that mentions, in the long (wrapped) command line, a recognizable JUnit suite. For that process, looking toward the left of the long (wrapped) line, get its process ID ... usually 4 or 5 digits. Then (almost there!) type "kill -3 <process-id>". I forget exactly what the '-3' means to Unix, but to Java, it means to take a dump of current data and thread states, You'll see a few messages to the console that a java dump wsa greated. That's the file that's handy to attach to a bugzills. (use sftp copy, if you do not have handier tools). That file is usually located in the /eclipse directory in use during the test.   
 
 
Feel free to edit this document with further tips (or, improve the directions above is I left out some steps, or, you've noticed things are slightly different than written here.
 
 
== Chronological Notes ==
 
 
This section is just to make quick notes about changes to our build files/scripts that others might find intersting.
 
 
=== Update prereqs to include official Eclipse M5 ===
 
<pre>
 
/downloads/drops/S-3.2M5-200602171115/
 
eclipse-SDK-3.2M5-win32.zip
 
eclipse-SDK-3.2M5-linux-gtk.tar.gz
 
eclipse-SDK-3.2M5-linux-gtk-ppc.tar.gz
 
eclipse-test-framework-3.2M5.zip
 
</pre>
 
There was an "odd" note when I downloaded the PPC version ...
 
<pre>
 
Eclipse fails to create a lock file with reason "No locks available."  To launch eclipse you must disable file
 
locking using the osgi.locking property. For example, you could launch eclipse as follows:
 
 
"eclipse -vmargs -Dosgi.locking=none".
 
</pre>
 
 
Thus, we *might* have to -Dosgi.locking=none on our PPC machine when we move to this M5 version of the base builder.
 
 
-- [[User:David williams|David williams]] 18:04, 21 February 2006 (EST)
 
 
 
 
=== 5/23/2006 Changes to build machine and CruiseControl ===
 
 
I've moved the
 
    /releng.builder/tools/cruise
 
stuff to another cvs project ... and called it
 
    /releng.control
 
 
The idea is that anything that is "machine specific" or "cruise control" specific  we can put in releng.control,  and have it under its own
 
versioning/update rules.  We'll attempt to keep the CVS version in synch with the eclipse.org PPC machine we use,
 
but other machines can be kept in "parallel" files, e.g. see
 
cruise-lomboz.properties
 
and rename them when deployed.
 
 
One implication (by design) is that "releng.builder" isn't downloaded and checked automatically by CruiseControl, in other words,
 
changes in it won't trigger a build. Not sure what is still used in "releng.builder", but know some things are, such as API checkers.
 
So, these API checkers will have to be downloaded or triggered by some other means (as has been our direction for a while).
 
 
Similar tor the "whatisfixed" tools .. I've turned it "off" by default ... it takes almost as long as the build itself!
 
So, we don't want to run it each build. Naci will be working on how to execute those separately against a
 
specific, declared build.
 
 
 
I've updated to cruise control 2.5 (they fixed that memory leak that was causing me to have to restart it every day or two).
 
(initially the 2.5 version was "crashing" frequently, but I think related to VM version, and seems to be running well now,
 
well ... for at least for 24 hours :)
 
 
I got the status is working again ... see
 
http://build.eclipse.org:7777/cruisecontrol/
 
 
 
[[User:David williams.us.ibm.com|David williams.us.ibm.com]] 21:02, 23 May 2006 (EDT)
 
 
=== drop/drivers moved to arhives/drops/drivers ===
 
 
To avoid mirroring our relatively temporary "drivers" directory, I've completed the move off
 
...webtools/downloads/drivers
 
to
 
/home/data/httpd/archive.eclipse.org/webtools/downloads/drivers
 
 
[[User:David williams.us.ibm.com|David williams.us.ibm.com]] 01:27, 27 May 2006 (EDT)
 
 
=== post 1.5 cleanup of drop site to archives site ===
 
 
For reference:
 
 
Pre-1.5 milestones and some old releases have been moved to
 
http://archive.eclipse.org/webtools/downloads/
 
 
Or, if you are navigating there directly, see
 
/home/data/httpd/archive.eclipse.org/webtools/downloads/drops
 
 
I've also moved the 0.7 translations there, see
 
/home/data/httpd/archive.eclipse.org/webtools/downloads/translations/
 
 
And, recall, we have some old, non-released pre-req drivers at
 
/home/data/httpd/archive.eclipse.org/webtools/downloads/drivers
 
 
These hopefully never have to be accessed, but, at the moment, if you do need one, the download
 
pages you'll find on the archive site are not quite operational.... their "links" still point to the "downloads"
 
area, instead of the "archived" area. But, the files are still there, so, for now, if you need one, you'll have to
 
get it via FTP, or, "manually" edit the URL to go to the archive area to download the zip file.
 
 
When some knowledgeable script experts have time, we may fix up the download pages, or,
 
we may simply make available in "directory list" form.
 
 
== A Quick Guide to Installing a WTP Build for Testing or as Development Target ==
 
 
WTP developers install WTP builds that are available at committers or downloads areas frequently for testing or using these as plugin development targets. Since each build has its own set of prerequisites, the installation process involves downloading WTP and its prereqs such as emf, gef, jem and eclipse sdk. To simplify this process I have created a scripts that uses the install scripst from the actual releng builder that was used to create a particular build.  To use it create simple eclipse project or just copy these scripts into a folder and run "ant -f install.xml get".  The script should do all the work for you. 
 
 
To use these scripts you should have apache ant (v1.6 or better), a JDK (v1.4.2 ro higher), and CVS installed on your machine.  They should be on your path.
 
 
 
First file you should create is the build.properties.  You modify this file to change the build you want to install or where you want files to be installed etc.  You should review these properties before each install:
 
 
 
<pre>
 
baseos=win32
 
basews=win32
 
basearch=x86
 
 
#-------------------------------------------------
 
# Build Stream are one of R0.7, R1.0, R1.5, R2.0
 
#-------------------------------------------------
 
wtp.buildStream=R1.5
 
 
#-------------------------------------------------
 
# Build area is one downloads or committers
 
#-------------------------------------------------
 
wtp.buildArea=committers
 
 
#-------------------------------------------------
 
# label of the Build to install
 
# e.g. M-1.5.1-200607141912
 
#
 
# cvstag is a derived label that you must provide
 
# in order to automtaically access the correct
 
# maps and wtp builder
 
# it is "v"+"buildType"+"buildTimeStamp"
 
# e.g. vM200607141912
 
#-------------------------------------------------
 
wtp.buildLabel=M-1.5.1-200607141912
 
wtp.cvsTag=vM200607141912
 
 
#-------------------------------------------------
 
# This is the home dir for build tasks
 
#  i.e. downloads folder etc.
 
#-------------------------------------------------
 
build.home=C\:/dev/build-home
 
 
#-------------------------------------------------
 
# This is where the deriver will be installed
 
#  i.e. downloads folder etc.
 
#-------------------------------------------------
 
targetDir=${build.home}/drivers
 
 
#-------------------------------------------------
 
# This is the folder under build.home where the
 
# scripts will look for previosly doenloaded files
 
#  i.e. downloads folder etc.
 
#-------------------------------------------------
 
build.local.repository=downloads
 
</pre>
 
 
 
Second file you should create is the ant script for installation, install.xml.  You do not need to modify anything in this this file, just change the properties we described before:
 
 
 
<pre>
 
<?xml version="1.0"?>
 
<!-- ======================================================================
 
    Properties that must be passed to this script can be found in
 
    build.properties
 
                                                             
 
    ====================================================================== -->
 
<project name="wtp-installer" default="get">
 
 
 
 
<property file="build.properties" />
 
<property file="./tmp/releng/maps/dependencies.properties" />
 
<property name="dependencyTargets" value="./tmp/releng.wtpbuilder/scripts/dependency/build.xml" />
 
<property name="local.cache.dir" value="${build.home}/${build.local.repository}" />
 
<property name="base.install.dir" value="${targetDir}/${wtp.buildLabel}" />
 
 
<!-- We form these properties dynamically to download the latest build -->
 
<property name="wtp.url" value="http://download.eclipse.org/webtools/${wtp.buildArea}/drops/${wtp.buildStream}/${wtp.buildLabel}" />
 
<property name="wtp.releng.url" value="http://download.eclipse.org/webtools/downloads/drivers" />
 
<property name="wtp.file" value="wtp-sdk-${wtp.buildLabel}.zip" />
 
<property name="wtp.name" value="WTP sdk ${wtp.buildLabel}" />
 
<property name="wtp.description" value="WTP sdk ${wtp.buildLabel}" />
 
 
<target name="get" depends="releng">
 
<delete dir="${base.install.dir}" failonerror="false" />
 
<mkdir dir="./tmp" />
 
<antcall target="releng" />
 
<antcall target="getAndInstall">
 
<param name="groupId" value="emf" />
 
</antcall>
 
<antcall target="getAndInstall">
 
<param name="groupId" value="gef" />
 
</antcall>
 
<antcall target="getAndInstall">
 
<param name="groupId" value="jem" />
 
</antcall>
 
<antcall target="getAndInstall">
 
<param name="groupId" value="eclipse" />
 
</antcall>
 
<antcall target="getAndInstall">
 
<param name="groupId" value="wtp" />
 
</antcall>
 
 
</target>
 
 
 
<target name="getAndInstall">
 
<ant antfile="${dependencyTargets}" target="checkDependency">
 
<property name="groupId" value="${groupId}" />
 
</ant>
 
<ant antfile="${dependencyTargets}" target="installDependency">
 
<property name="groupId" value="${groupId}" />
 
<property name="install.destination" value="${base.install.dir}" />
 
</ant>
 
</target>
 
 
 
<target name="releng">
 
 
<available file="./tmp/releng/maps/dependencies.properties" property="map.exists" />
 
<available file="./tmp/releng.wtpbuilder/scripts/dependency/build.xml" property="releng.exists" />
 
<antcall target="checkout-maps" />
 
<antcall target="getwtpbuilder" />
 
</target>
 
 
<target name="checkout-maps" unless="map.exists">
 
 
<cvs quiet="true" cvsRoot=":pserver:anonymous@dev.eclipse.org:/cvsroot/webtools" package="releng/maps/build.cfg" dest="./tmp" tag="${wtp.cvsTag}" />
 
<cvs quiet="true" cvsRoot=":pserver:anonymous@dev.eclipse.org:/cvsroot/webtools" package="releng/maps/dependencies.properties" dest="./tmp" tag="${wtp.cvsTag}" />
 
 
</target>
 
 
<target name="getwtpbuilder" unless="releng.exists">
 
<property file="./tmp/releng/maps/build.cfg" />
 
<delete dir="./tmp/releng.wtpbuilder" failonerror="false" />
 
<echo message="Version tag for releng.wtpbuilder is: ${wtpBuilderVersion}" />
 
<cvs quiet="true" cvsRoot=":pserver:anonymous@dev.eclipse.org:/cvsroot/webtools" package="releng.wtpbuilder/scripts/dependency" dest="./tmp" tag="${wtpBuilderVersion}" />
 
 
</target>
 
 
 
</project>
 
 
 
</pre>
 
 
== Background and Further Reading References ==
 
 
We in WTP following the basic process and recommendations for versioning as the base Eclipse platform.
 
[http://www.eclipse.org/equinox/documents/plugin-versioning.html Plugin Versioning]
 
 
Very helpful guide to builds and automatic testing.
 
[http://www.eclipse.org/articles/Article-PDE-Automation/automation.html Build and Test Automation for plug-ins and features]
 
 
Good step-by-step on how to do updates. [http://www.eclipse.org/articles/Article-Update/keeping-up-to-date.html How To Keep Up To Date]
 
 
We base our builds on the Eclipse platform's "basebuilder".
 
[http://wiki.eclipse.org/index.php/Platform-releng Platform-releng]
 
 
With our WTP specific needs addressed in the WTP project called releng.wtpbuilder.
 
While slightly out of date, see the [[https://bugs.eclipse.org/bugs/attachment.cgi?id=26584 attachment]] to [[https://bugs.eclipse.org/bugs/show_bug.cgi?id=108259 bug 108259]]
 
 
Our basic server configuration and cruise control triggers is handled by the WTP project called releng.builder (see especially the tools/cruise directory in that project).
 
 
And ... never forget [http://help.eclipse.org/help31/index.jsp Eclipse Help] ... search for things related to update manager, PDE, features, site.xml, etc.
 

Latest revision as of 22:55, 12 September 2008