geWorkbench

Release Check List

Here is a list of things we need to do/test before putting a new release on the site:

• Check that the main menu option Help->Version lists the correct application and component versions.
• Check that the release notes are complete.
• Check that the online help associated with each component is correct and that it has been versioned using the same version as the one of the component.
• Verify builds for all platforms by installing/running them in "virgin" environments.
• Check that the technical documentation associated with each compoenent is up to date and that it has been versioned using the same version as the one of the component.
• Deploy new Javadocs documentation on the geWorkbench site.

Requirements To Consider

• All gew components should implement the interface WorkbenchPlugin which defines a number of methods such as:
  • String getLabInfo(): returns information about the lab where the component originated from.
  • String getLicenseInfo(): returns license information.
  • String getLibraries(): returns information about 3rd party libraries (with approrpiate attribution).
  • VersionInfo getVersion(): returns the version of the component.
• Modify VisualPlugin::getComponent() to return an object of type WorkbenchVisualComponent that extends Component and provides ways to display originating Lab, licence info, libraries and version.

Misc

• Setup nightly build.

Ken's tutorial

temp tutorial

Collaborative Development

We encourage developers of geWorkbench plugins to use our CVS server infrastructure. Our source code tree comprises 2 separate CVS modules named geWorkbench and components which corespond to the core and plugin code portions outlined in the "Developers" section.

Collaborative development takes place under the components module. The module contains a number of subdirectories, each corresponding to one geWorkbench plugin. Each subdirectory has the same basic structure:

• A src directory containing the plugin code.
• An optional lib directory containing jar files required by the plugin.

The application ant build script (which is made available to collaborative developers) will also create a classes directory which will contain the executable code. To create a new plugin called "example" a new directory with the same name will be created under the components module and CVS accounts will be issued to the members of the component development team. All developers in that team will become members of a new Unix group which will own the subdirectory (the rest of the world will have read-only rights).

A full development environment can be then obtained by checking out the 2 project CVS modules, "geWorkbench" and "components". In this development space the plugin development team will be able to change the code of their plugin as they please, check it in and out of CVS, use all the available build scripts, etc. However, they will only have read rights to the core "geWorkbench" module.

Links from old "Developer" section

• Introduction For Developers
• Instructions for the Developer Kit
• Building geWorkbench
• Coding Standards Style Guide
• Javadocs
• CVS Repository
• Screenshots
• Information on .GEAR files, a method of distributing plugins.
• Plugin certification checklist