Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[wtp-dev] Tip for running local builds to test code changes before committing

The WTP build policy adopts several general principals from various sources (See WTP build page), one of which is continuous integration (

Here are some interesting quotes:

"It's important that any developer can simulate the master build locally on their own machine. That way if an integration error does occur, a developer can investigate and debug the problem on their own machine without tying up the master build process. Furthermore the developer can run the build locally before checking in to reduce the chances of the master build failing."

"We also leave to the developer's judgement how careful they should be before checking in. It's up to developer how likely they think it is that there will be an integration error. If she thinks it is likely, then she does a local build first before checking in, if she thinks an integration error is unlikely then she will just check in. If she's wrong she'll find out once the master build runs and then she'll have to back out her changes and figure out what went wrong. You can tolerate errors providing they are quick to find and easy to remove."

I hope the following will make it a more pro-active approach...

For those of you who strive to be diligent about committing code without breaking builds, I've modified the wst build (changes yet to be checked in) so that you have the _option_ to test out whether the feature and/or plugin patches that you create will build successfully locally using the WTP build process.    Also, you can test out whether any map file changes that you make will not break the build.

Since the build process does a cvs extract, non-committers cannot readily verify the changes they make will break the build.  Hence, by overlaying map files and applying feature and/or plugin patches at strategic points in the build process, one can simulate a WTP build that includes the developer's changes, on his own local machine.

Here's how it works.

There are three properties in the file that will be in org.eclipse.wtp.releng.   Uncomment the property or properties you wish to use and modify the values accordingly.  Of course, as it stands (all commented out), the WTP build will run the usual way with no overlays.

#This specifies where modified map files to overlay (non-patches) are located.

# This specifies where your feature patches are located.
# This should be different than the pluginPatchesFolder

# This specifies where your plugin patches are located.
# This should be different than the featurePatchesFolder

For the map file folder, ensure you have all the map files, not just the ones you edited (The build script will first remove the maps directory that was extracted from cvs.)  We can change this to use patches later.

For any plugin or feature patches, just put them in their respective directories.  Note that for the "patch" ant task to work. you need to get patch.exe (see ANT task reference; grab it from the net) and put it on your PATH.  The patches will be applied after the fetch step.

Here is an example output:

     [java] postFetch:

     [java] applyFeaturePatches:
     [java]      [echo] Applying patches in: D:/wtpBuild/Overlay/patches/features
     [java]      [echo] Destination: D:/wtpBuild/buildDirectory/features
     [java]  [patchall] Applying patch org.eclipse.wst.patch
     [java]  [patchall] patching file feature.xml

     [java] applyPluginPatches:
     [java]      [echo] Applying patches in: D:/wtpBuild/Overlay/patches/plugins
     [java]      [echo] Destination: D:/wtpBuild/buildDirectory/plugins
     [java]  [patchall] Applying patch org.eclipse.wst.wsdl.patch.txt
     [java]  [patchall] patching file plugin.xml

To make the 'patch' process automatic, a naming convention on the patch file is required:  please name the patch with the plugin/feature name followed by .patch.*.     For example,


ie. For the feature org.eclipse.wst, these are valid patch names:


This is invalid:  org.eclipse.wst.feature.txt

The patchall ant task will use the substring up to the word ".patch" as the folder in which the patch file will be applied.  (Similarly, if you apply a patch from the workbench, you must specify the folder, and the patch file).

Here are the files that have to be changed/added.  (sorry, I didn't create any patches ;-)  )

- modified, from org.eclipse.wtp.releng\buildAll.xml

- new, place in org.eclipse.wtp.releng

- new, place in org.eclipse.wtp.releng

 - modified, from org.eclipse.wtp.releng\wst\customTargets.xml

So, here are the steps to test out your patches:

1. Set up your folders where you will place your patches/map files
2. Create your patches (follow naming conventions) and put them in their designated folders
3. Modify
4. Run the build

Future ideas?  Get this working on linux?  Apply the changes to other customTargets?

Keith Chong
Phone: (905) 413-4370    T/L: 969-4370
e-mail: kchong@xxxxxxxxxx

Attachment: buildAll.xml
Description: Binary data

Description: Binary data

Attachment: wtpTasks.jar
Description: Binary data

Attachment: customTargets.xml
Description: Binary data

Back to the top