[wtp-dev] Tip for running local builds to test code changes before commi

[Keith Chong <kchong@xxxxxxxxxx>]

The WTP build policy adopts several
general principals from various sources (See WTP build page), one of which
is continuous integration (http://www.martinfowler.com/articles/continuousIntegration.html):

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
custom.properties 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.
#replaceMapsFolder=D:/wtpBuild/Overlay/maps

# This specifies where your feature
patches are located.
# This should be different than the
pluginPatchesFolder
#featurePatchesFolder=D:/wtpBuild/Overlay/patches/features

# This specifies where your plugin patches
are located.
# This should be different than the
featurePatchesFolder
#pluginPatchesFolder=D:/wtpBuild/Overlay/patches/plugins


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, 

<pluginname|featurename>.patch.*

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

org.eclipse.wst.patch
org.eclipse.wst.patch.txt

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 custom.properties
4. Run the build 


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


Regards,
Keith Chong
D3/QCS/8200/MKM
Phone: (905) 413-4370    T/L: 969-4370
e-mail: kchong@xxxxxxxxxx

Attachment: buildAll.xml
Description: Binary data

Attachment: custom.properties
Description: Binary data

Attachment: wtpTasks.jar
Description: Binary data

Attachment: customTargets.xml
Description: Binary data