WTP Development Practices
WTP Development Practices

This document is to describe some guidelines, procedures, and "best practices" for doing WTP development. In some cases its simply covers consistency/procedure issues, but also recommends best practices to help community review and involvement. While all component teams can have their own practices, if anyone has some good tips or recommendations, please post to wtp-dev for discussion or suggest that they be added here.

Code into CVS

The component developers should provide the following information to accompany code checked into CVS. Some of this information will become part of the components 'development' directory in cvs, or on the component's WTP website, and should be kept up to date as changes take place and development progresses. (See Web and development resources for guidelines on what goes where).

Modified Code into CVS

As features are added to bugzilla and fixes done and patches are applied, enter the CVS commit comment as
[BUGNO] Bugzilla abstract or explanation (eg: [6788] Fixed NPE on open)
This will allow us to generate a "what is fixed " list automatically with links to bugzilla with each build. For an example of output in another project, see

Plugin Design Conventions

Avoid using the export="true" attribute on pre-req (imported) plugins.

Its never appropriate to use it just so your upstream clients save typing a line in their plugin.xml file. But, sometimes it is appropriate to use it -- when the classes/interfaces in pre-req plugin really are part of the pre-reqing plugins API. If it fits this later case, that is it is part of the plugin's API, please document what part of the API requires it. For example:
<!-- need to re-export org.eclipse.text since our API depends on it,
such as IStructuredDocument extends IDocument
<import plugin="org.eclipse.text" export="true"/>

The reason for this convention is that it forces upstream clients to stay better aware of exactly what they are pre-reqing instead of picking up some classes simply as a side effect of pre-reqing your plugin.

Web and development resources

By convention, a directory named 'development' should be used in the component's CVS directory structure. This directory would be a peer with 'features' and 'plugins'. These directories should hold things that may be useful or relevant not only to the developers of the components, but others interested in contributing (e.g. project team sets, Rose source files of designs, etc). Things in these directories are not intended to be in a build. If they are intended for an SDK build, they would be part of the plugins directory structure.

[Note: there's some CVS work still needed to map the website to an area in CVS, so the following paragraph will be expanded after that is established]

For resources that are to be published or linked on the WTP web site, there will be an area in CVS that parallels the website, so resources that are placed there will be periodically copied to the whosoever for proper serving.

Streams and Builds

Code into a Build

Nightly, Weekly, Milestone Builds

Nightly builds will be built from the head stream. Occasional compile errors or unit tests failures would not be abnormal, but should be fixed by the next nightly build.

Weekly integration builds will be built from developer tagged versions. There should never be compile errors or unit tests failures in an integration build, but if that happens then 1) immediate fixes are required and 2) the offender must wear a red clown nose for the day :). Integration builds are expected to be of sufficient quality they can be used as the target in the development environment, though will have received little or no testing.

Milestone builds are like weekly integration builds except they get substantial testing. The expectation is that milestone builds be of sufficient quality that they can be used to self host development.

Streams, Streams, and more Streams

Most development should take place in the HEAD stream. However, if a component knows its making large breaking changes that would cause clients a lot of churn (such as daily changes, to avoid breaking nightly build), they can do the major changes in a temporary branch. The component team should keep everyone informed that major development is occurring in a branch, and naturally, well coordinate the merge back into the HEAD stream. A good guideline is that development on a branch should not occur for more than 3 weeks without being merged back into HEAD.

Self Assessment

The following criteria can be useful to self-measure the success of a milestone or release. Component leads should monitor their progress with these expectations in mind.