WTP/Build/WTP Patches for Release 2.0.2
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, if there is one ... 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 :) need to mess with patches. There should be very few, very special purpose, handled and produced on a case-by-case bases.
For WTP 2.0.2 -- for now -- there is no special stream that contains code related to these patches. That is, these fixes will be released to the R2_maintenance stream. (If there is not already such a stream for a component, it will of course have to be created).
The map files used will continue to be pulled from the R2_maintenance branch.
There is a special component
releng.wtpbuilder cvs project that along with special distribution targets
patches.build patches.site patches.upload patches.tests
will produce patch features that contains a special feature to "host" the plugin. See Eclipse Help for details on patch features.
The patch feature is typically a "brand new" feature, and must be added to a map file (in the R2_maintenance stream). Of course, if that feature already exists, and another plugin is being added to it, then it only needs the new version released to the R2_maintenance branch.
These patch features must correspond to the "build component features" since those are the assumed lowest unit by which anyone consumes our features (for example, xml_core.feature.patch ... usually not lower, such as xsd.feature.patch, nor higher, such as wst.feature.patch).
The end-result is
- a compressed archive (zip file) 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 download web page, but when appropriate will be copied to the official /webtools/updates site.
If it is desired to be generally available to all WTP users (by them using the Eclipse Update Manager), then the update features and plugins have to be copied to the downloads/webtools/updates directory. If update is done, remember to
- update the site.xml
- recreate the digest
- run pack200
Bugs which will be made public on update site must go through PMC Review and typically some regression testing before being put on update site, since in theory any such fixes could effect other adopters/products, so needs extra review.
Getting the feature patch in to a build
There is a special feature that drives the patch build:
The feature patch which hosts the fixed bundle needs to be added to this special feature, and all released to the releng project (maps) in the R2_maintenance branch.
The patch build is not done automatically but must be started manually from the "force build" button on the dashboard.
These are tips on avoiding problems that have been hit before. They are especially problematic, since everything may appear to work fine, but then various install or update manager scenarios will not work.
- The patch feature must "requires" the feature that it is patching, including all 4 fields of the version -- the 'qualifier' field is not computed automatically during the batch build, as other qualifiers are. This won't show up as a problem just unzipping the features and plugins, but will when update manager is used.
- Remember to "match" features and patch features ... that is, if a plugin is in another feature, besides the one that the patch feature 'requires', then various paths of using update manager won't work. For WTP, this is most easily accomplished by having patch features which parallel the build component features.
- Be positive that the "unpack" attribute of the include plugin element is exactly the same in the original feature, and the patch feature. If it was unpacked in the original, it must be unpacked in the patch. Again, this won't often show up as a problem until much later in the process.
Feel free to ask questions on
firstname.lastname@example.org if there are questions.