WTP Release 1.5 Patches
What is an "official patch"?
Under some circumstance the WTP project may find it desirable to produce a "feature patch" which typically includes exactly one jar, that has a fix for exactly one bug. These are done for bugs which happen to be considered extremely severe or blocking -- but may not even apply to all installs, or all users. (So, as a general rule, they are not to be installed by everyone ... but any bugs fixed by patches will be fixed in the next maintenance release ... though the exact fix might be different).
While few, it is important to create and apply these in a controlled, repeatable process in order to maintain product level professional quality. For example, it is important to compile with exactly the same compiler, and exactly the same "pre-reqs" that was used to create the original build.
Normally, only the "releng team" (ok ... me and Naci :) need to mess with patches. There should be very few, very special purpose, handled and produced on a case-by-case bases.
There is a special stream to that contains code related to these patches:
There is a special component
releng.wtpbuilder cvs project that along with special distribution targets
patches.build patches.site patches.tests patches.upload
that produce patch features that contains a special feature to "host" the plugin. (See Eclipse Help for details).
The end-result is
- a compressed archive on http://download.eclipse.org/webtools/patches/
- a feature and plugin suitable for an update site. These update jars are actually in the same directory as the zip download, but normally not visible from the web. It is assumed they will be put in the right place by a release engineer, where the
- the site.xml needs to be updated,
- the digest needs to be re-created, and
- pack200 re-ran.
Currently, there are a few "manual" updates needed to tweak the build, to create a feature patch.
- In the
build.propertieshas a field,
patchFeaturethat needs to be updated for the particular patch feature that is being created. Additionally, there is one target name in
customTargest.xmlfile that needs to be updated. It is the one that starts with
assemble(who knew ant target's can not contain variables?).
- In the
config.xmlfile that is in the
buildIdproperty of the
tp-P-1.5build project target needs to be update to be what ever nifty name you pick for the zip file (usually the bug number).
- And, of course, everything needs to be versioned and updated and the CruiseControl server needs to be re-started to get the buildId to apply.
Feel free to ask questions on
email@example.com if there are questions.