http://wiki.c2b2.columbia.edu/workbench/api.php?action=feedcontributions&feedformat=atom&user=ZjigeWorkbench - User contributions [en]2026-04-30T14:23:49ZUser contributionsMediaWiki 1.27.7http://wiki.c2b2.columbia.edu/workbench/index.php?title=File:ExampleComponent.gif&diff=11569File:ExampleComponent.gif2013-11-13T16:56:56Z<p>Zji: uploaded a new version of &quot;File:ExampleComponent.gif&quot;</p>
<hr />
<div>Screenshot of the example component.</div>Zjihttp://wiki.c2b2.columbia.edu/workbench/index.php?title=File:ProjectArea.png&diff=11568File:ProjectArea.png2013-11-13T16:54:09Z<p>Zji: uploaded a new version of &quot;File:ProjectArea.png&quot;</p>
<hr />
<div>The Project Panel.</div>Zjihttp://wiki.c2b2.columbia.edu/workbench/index.php?title=Developers&diff=11567Developers2013-11-13T16:21:30Z<p>Zji: </p>
<hr />
<div>{{DevelopersTopNav}}<br />
<br />
geWorkbench is an open source Java-based platform and contributions by members of the community are welcome and encouraged. The latest code under development <br />
is hosted on GitHub<br />
https://github.com/geworkbench-group. Anonymous read access is supported for all the code.<br />
<br />
<br />
Development in geWorkbench takes place along 2 lines:<br />
* <u>'''geWorkbench core'''</u>: this portion of the code includes mainly 7 groups of packages:<br />
# ''engine'', which implements services related to the geWorkbench component architecture framework (e.g., plugin instantiation and visual layout, message delivery, component registry management, etc)<br />
# ''bison'' ('''B'''iomedical '''I'''nformatics '''S'''tructured '''ON'''tology) which contains the definition of the bioinformatics data types which form the basis of communication between the geWorkbench plugins.<br />
# ''builtin'', supporting the internal execution and coordination of the core process, especially the project panel<br />
# ''parsers'', parsing supports for input data format<br />
# ''events'', event classes used by communication between all components and the core<br />
# ''util'', all the utility libraries<br />
# ''analysis'', a small number of classes providing abstract for analyses and savable parameter settings. This group used to be called "others" to include miscellaneous; ''analysis'' is the only one left now. This probably will be re-organized in the future.<br />
* <u>'''geWorkbench plugin components'''</u>: this portion of the source tree contains the code for the various application plugin components (sample code for creating a simple plugin can be found [[A_Simple_Plugin |here]])<br />
<br />
There are no restrictions on who can develop a new component for geWorkbench. You can work against the development version or a release version of the geWorkbench core. To contribute your component to geWorkbench code, you need write access to the subversion server. Please contact us for the procedure.<br />
Contributions to the geWorkbench core packages are more controlled in order to avoid changes that may adversely affect large numbers of plugins.</div>Zjihttp://wiki.c2b2.columbia.edu/workbench/index.php?title=Download_and_Installation&diff=11157Download and Installation2013-10-03T14:55:14Z<p>Zji: /* geWorkbench 2.4.1 (released October 26th, 2012) */</p>
<hr />
<div>{{DownloadTopNav}}<br />
<br />
<br />
This section contains instructions for '''downloading''' and '''installing''' geWorkbench.<br />
<br />
=Notice - Downloads from NCI not usable=<br />
October 1st, 2013 - Downloads of geWorkbench from the NCI GForge site are not usable due to a server error. The files appear to download correctly but have a server-side error message prepended to them, making them unusable. Because of the government shutdown, it may be some time before this download site is again usable. <br />
<br />
You can now download geWorkbench instead directly from our own site, using the links in the section below.<br />
<br />
=Downloads=<br />
<br />
You can now download geWorkbench directly from our server. Choose the appropriate version below.<br />
<br />
==geWorkbench 2.5.0==<br />
<br />
geWorkbench 2.5.0 is scheduled for release on October 4th, 2013. It adds a number of new features, and restores geWorkbench compatibility with external BLAST and gene annotation services.<br />
<br />
<br />
<br />
==geWorkbench 2.4.1 (released October 26th, 2012)==<br />
<br />
[[Media:GeWorkbench_v2.4.1.md5.txt | geWorkbench 2.4.1 MD5 Sums file]]<br />
<br />
[http://magnet.c2b2.columbia.edu/?q=node/44&software=geWorkbench geWorkbench_v2.4.1_Generic.zip]<br />
<br />
[http://magnet.c2b2.columbia.edu/?q=node/44&software=geWorkbench&platform=Linux geWorkbench_v2.4.1_Linux_installer_noJRE.bin]<br />
<br />
[http://magnet.c2b2.columbia.edu/?q=node/44&software=geWorkbench&platform=Linux_with_JRE geWorkbench_v2.4.1_Linux_installer_with_JRE6.bin]<br />
<br />
[http://magnet.c2b2.columbia.edu/?q=node/44&software=geWorkbench&platform=MacOSX geWorkbench_v2.4.1_MacOSX_installer.zip]<br />
<br />
[http://magnet.c2b2.columbia.edu/?q=node/44&software=geWorkbench&platform=Windows geWorkbench_v2.4.1_Windows_installer_noJRE.exe] <br />
<br />
[http://magnet.c2b2.columbia.edu/?q=node/44&software=geWorkbench&platform=Windows_with_JRE geWorkbench_v2.4.1_Windows_installer_with_JRE6.exe]<br />
<br />
=geWorkbench 2.4.1 - System Requirements=<br />
==Java== <br />
* The Java 6 Runtime Environment (JRE6) is required. geWorkbench will run using Java 7, but has not been tested extensively in that environment. Several incompatibilities have already been seen under Java 7 (see [[Known_Issues|Known Issues]] for details).<br />
* For Windows and Linux, geWorkbench is distributed in two installer forms, one with and one without the JRE6 included. To install a version of geWorkbench that does not include the JRE, the JRE6 must be installed separately on the machine. <br />
* On MacOSX, the Java 6 JRE is included with MacOSX versions 10.5 and higher with the latest updates (Intel platforms only). Java 6 is not available for the PowerPC platform.<br />
* The "Generic" distribution of geWorkbench does not include the JRE6. It must be installed separately.<br />
* geWorkbench can run on both 32-bit and 64-bit versions of Java on appropriate OS platforms.<br />
<br />
<br />
===How to choose===<br />
* Using an installer version of geWorkbench that inludes the JRE6 allows you to be sure that you are running geWorkbench with the correct version of the JRE. <br />
* You may wish to install a "no JRE" version of geWorkbench if you want to choose between 32 and 64 bit JREs, to keep up with the latest updates to the JRE, or to experiment with Java 7.<br />
<br />
===Obtaining the Java 6 JRE===<br />
* The JRE6 can be downloaded from http://www.oracle.com/technetwork/java/javase/downloads<br />
* Note: Java 6 is also referred to as Java 1.6.<br />
<br />
==Display Driver==<br />
* This requirement pertains only to using the PCA component 3D graph viewer.<br />
* When using a 64-bit JVM, the Java 3D library requires that OpenGL version 1.2 or higher be supported by your display driver.<br />
<br />
==Memory== <br />
At least 2 GB is recommended. geWorkbench 2.4.1 by default will request up to 1 GB of memory for the Java VM.<br />
<br />
==Operating System==<br />
* '''Windows XP/Vista/Windows 7 (32 or 64-bit)''': no special requirements.<br />
<br />
* '''MacOSX''': Version 10.5 with latest updates, or any higher version (10.6, 10.7 +) is required to provide the Java 6 JRE (Intel platform only).<br />
<br />
* '''Linux''': A version of Java must already be installed on the machine in order to run the geWorkbench installer.<br />
<br />
geWorkbench, unless otherwise noted for particular components, can be run on both 32 and 64-bit operating systems and JREs.<br />
<br />
==Graphics Driver==<br />
At least one component, the PCA viewer, uses a Java 3D library. When using a 64-bit JVM, the Java 3D library requires OpenGL version 1.2 or higher to be supported by the graphics display adapter in your computer.<br />
<br />
<br />
==R server==<br />
The SAM analysis component can use a local installation of R on your desktop computer.<br />
<br />
This has been tested with R version 2.15.0.<br />
<br />
At least for Windows 7 installations, it may be necessary to have R installed in a user directory rather than in a system directory, e.g. to "c:\users\username\R-2.15.0", where "username" is your own account name.<br />
<br />
=IMPORTANT NOTICE ABOUT THE LICENSE=<br />
Use of geWorkbench is governed by the rules specified in the [[geWorkbench License | software license]]. Please make sure to read the license and understand your obligations before proceeding to download the application.<br />
<br />
<br />
<br />
=Installation Instructions=<br />
<br />
All three platform-specific versions of geWorkbench (Windows, Linux, and Macintosh) provide an installation wizard (generated using InstallAnywhere).<br />
<br />
* Using an installer version of geWorkbench that inludes the JRE6 allows you to be sure that you are running geWorkbench with the correct version of the JRE. <br />
* You may wish to install a "no JRE" version of geWorkbench if you want to choose yourself between 32 and 64 bit JREs, or to keep up with the latest updates to the JRE.<br />
* On Windows and Linux, geWorkbench was tested using installer versions which included the JRE6. The included JREs are 32-bit versions.<br />
<br />
A generic version of geWorkbench, which does not use any installer, is also available, and should run on any machine which supports Java 6.<br />
<br />
Further information about the [http://www.flexerasoftware.com/products/installanywhere/requirements.htm InstallAnywhere requirements] are found at the Flexera website.<br />
<br />
<br />
==Windows (XP/Vista/Windows 7)==<br />
<br />
===Special note for Vista/Windows 7===<br />
If you run the installer on Vista or Windows 7, the installer will prompt you to install geWorkbench to your user home directory, e.g. '''C:\Users\''username''\geWorkbench_2.4.1''', where ''username'' is your Windows login name.<br />
<br />
===Installer with JRE6===<br />
* File: geWorkbench_v2.4.1_Windows_installer_with_JRE6.exe<br />
* Includes the 32-bit Sun Java 6 JRE.<br />
<br />
Download and double-click the installer file to begin installation.<br />
<br />
===Installer without JRE6=== <br />
* File: geWorkbench_v2.4.1_Windows_installer_noJRE.exe<br />
* No JRE is included, you must make sure that an appropriate Java 6 JRE is installed on your system before installing geWorkbench.<br />
<br />
Download and double-click the installer file to begin installation.<br />
<br />
==MacOSX==<br />
<br />
* File: geWorkbench_v2.4.1_MacOSX_installer.zip.<br />
* This version uses the Java 6 JRE included with recent updates to the MacOSX operating system. (Intel platforms only).<br />
<br />
Double-click geWorkbench_v2.4.1_MacOSX_installer.zip to begin installation. This will extract a file called "install". Double-click on this file to install geWorkbench.<br />
<br />
===Notes===<br />
* Requires Mac OS X 10.5 with recent updates, or 10.6 or 10.7+.<br />
* As Java 6 is not available for the PowerPC platform, regardless of OS X version, geworkbench will not run on the PowerPC platform under any version of OS X.<br />
* The compressed installer should be expanded automatically by the system.<br />
<br />
==Linux==<br />
<br />
===Installer with JRE6=== <br />
* File: geWorkbench_v2.4.1_Linux_installer_with_JRE6.bin.<br />
* Includes the 32-bit Sun Java 6 JRE.<br />
<br />
===Installer without JRE6=== <br />
* File: geWorkbench_v2.4.1_Linux_installer_noJRE.bin.<br />
* No JRE is included, you must make sure that an appropriate Java 6 JRE is installed on your system before installing geWorkbench.<br />
* You may need to configure the JRE. See section below, "Java Environment Configuration".<br />
<br />
===Installation===<br />
You must already have installed a version of Java 1.6 or later on your Linux machine in order to run the geWorkbench installer.<br />
<br />
The Linux version of geWorkbench relies on X-Windows being installed and running. If you are running Linux on a server and e.g. you wish to view the application on a Windows desktop, you will also need to run an X-windows server on your desktop machine. See X-Windows configuration instructions below.<br />
<br />
After downloading, cd (if needed) to the directory to which you downloaded the installer.<br />
<br />
To begin the installation, type the command for the particular version, e.g. for the installer with JRE: <br />
<br />
"sh ./geWorkbench_v2.4.1_Linux_installer_with_JRE6.bin".<br />
<br />
This will extract geWorkbench into a new directory called geWorkbench_2.4.1.<br />
<br />
<br />
If you requested that a desktop link be created, it will be called rungeWorkbench_2.4.1.<br />
<br />
Note - if you made changes to the default installation directory name, the shortcut link may just be called "geWorkbench_2.4.1" rather than "rungeWorkbench_2.4.1".<br />
<br />
===Running geWorkbench (Linux)===<br />
To run geWorkbench, and assuming you are using the Linux bash shell, and that you created a shortcut link during installation, issue one of the following commands from your home directory: <br />
<br />
./rungeWorkbench_2.4.1 <br />
or<br />
sh rungeWorkbench_2.4.1.<br />
or<br />
sh geWorkbench_2.4.1 if the link received the alternative name (see above).<br />
<br />
Alternatively, in the directory in which geWorkbench was installed, you can start geWorkbench with the command:<br />
<br />
sh launch_geWorkbench.sh<br />
<br />
==Generic==<br />
A non-installer-based version of geWorkbench is supplied in a Zip file which should work on any platform.<br />
<br />
File: geWorkbench_v2.4.1_Generic.zip<br />
<br />
===Installation=== <br />
<br />
Unzip the file. It will create a directory geWorkbench_2.4.1.<br />
<br />
<br />
===Running geWorkbench (generic)===<br />
<br />
You must have the Java 6 JRE installed and the JRE must be in the path for geWorkbench (see Java Environment Configuration below).<br />
<br />
Windows: you can double click on the file "launch_geWorkbench.bat" to launch geWorkbench, or run it from a command window.<br />
<br />
Linux/Unix: Execute the script "launch_geworkbench.sh".<br />
<br />
Any: Alternatively, if you have Apache Ant installed, you can type "ant run" in the geWorkbench directory.<br />
<br />
=Java Environment Configuration=<br />
<br />
To run a version of geWorkbench that does not include the Java 6 Runtime Environment (JRE6), the JRE6 must be installed and, depending on the platform configured separately.<br />
<br />
Two environment variables may need to be properly configured. These are the JAVA_HOME and the PATH variables. They should be configured to point to your own installation of the JRE6. <br />
<br />
Here is an example of setting the two environment variables for a JRE installed in the directory /opt:<br />
<br />
JAVA_HOME=/opt/jre1.6.0_31<br />
<br />
PATH=/opt/jre1.6.0_31/bin:$PATH<br />
<br />
=Typical steps in running X-windows=<br />
Here are some typical steps to configure a remote Linux host and a local desktop X-server. Under Windows, a local X-server can be provided for example by the Cygwin package.<br />
<br />
On the remote Linux host (assuming you are using the bash shell), issue the command<br />
* "export DISPLAY=(your IP):0"<br />
where (your IP) should be substituted with the IP address of your local desktop machine.<br />
<br />
On your local desktop machine, you may need to<br />
# start the X-windows server with a command such as "startx". You may need to cd to the X11 bin directory to find this command.<br />
# allow remote connections with a command such as "xhost +".<br />
<br />
=Quick Start=<br />
A [[QuickStart| Quick Start]] guide to geWorkbench is being developed.<br />
<br />
=Community Support Forums=<br />
geWorkbench community forums are operated by the caBIG Molecular Analysis Tools Knowledge Center. There are separate user and developer forums. Anyone can browse through existing postings, but to start a new topic one must first register.<br />
<br />
The forums can be viewed at https://cabig-kc.nci.nih.gov/Molecular/forums/<br />
<br />
<br />
=Tutorial data=<br />
<br />
[[Media:tutorial_data.zip|tutorial_data.zip]] (3.586 MB) - data files in several different formats useful for the tutorials or just trying out geWorkbench.<br />
<br />
[[Media:Bcell-100.zip|Bcell-100.zip]] (5.256 MB) - A large (100 array) microarray dataset in the geWorkbench matrix format. Data is from the lab of Riccardo Dalla-Favera, Columbia University, and is provided only for use in learning and testing geWorkbench. It was obtained from experiments using Affymetrix HG-U95Av2 chips. This file contains the same data as the previously used file "webmatrix", but with the array subsets given more descriptive names.<br />
<br />
<br />
=Training Slides=<br />
A set of PowerPoint training slides for an earlier version of geWorkbench is still available, but is of historical interest only. The PowerPoint file is available from the [[Project Documentation]] section of this site.</div>Zjihttp://wiki.c2b2.columbia.edu/workbench/index.php?title=Download_and_Installation&diff=11156Download and Installation2013-10-03T14:52:25Z<p>Zji: /* geWorkbench 2.4.1 (released October 26th, 2012) */</p>
<hr />
<div>{{DownloadTopNav}}<br />
<br />
<br />
This section contains instructions for '''downloading''' and '''installing''' geWorkbench.<br />
<br />
=Notice - Downloads from NCI not usable=<br />
October 1st, 2013 - Downloads of geWorkbench from the NCI GForge site are not usable due to a server error. The files appear to download correctly but have a server-side error message prepended to them, making them unusable. Because of the government shutdown, it may be some time before this download site is again usable. <br />
<br />
You can now download geWorkbench instead directly from our own site, using the links in the section below.<br />
<br />
=Downloads=<br />
<br />
You can now download geWorkbench directly from our server. Choose the appropriate version below.<br />
<br />
==geWorkbench 2.5.0==<br />
<br />
geWorkbench 2.5.0 is scheduled for release on October 4th, 2013. It adds a number of new features, and restores geWorkbench compatibility with external BLAST and gene annotation services.<br />
<br />
<br />
<br />
==geWorkbench 2.4.1 (released October 26th, 2012)==<br />
<br />
[[Media:GeWorkbench_v2.4.1.md5.txt | geWorkbench 2.4.1 MD5 Sums file]]<br />
<br />
[{{SERVER}}/workbench/data/geWorkbench_v2.4.1_Generic.zip geWorkbench_v2.4.1_Generic.zip]<br />
<br />
[{{SERVER}}/workbench/data/geWorkbench_v2.4.1_Linux_installer_noJRE.bin geWorkbench_v2.4.1_Linux_installer_noJRE.bin]<br />
<br />
[{{SERVER}}/workbench/data/geWorkbench_v2.4.1_Linux_installer_with_JRE6.bin geWorkbench_v2.4.1_Linux_installer_with_JRE6.bin]<br />
<br />
[{{SERVER}}/workbench/data/geWorkbench_v2.4.1_MacOSX_installer.zip geWorkbench_v2.4.1_MacOSX_installer.zip]<br />
<br />
[http://magnet.c2b2.columbia.edu/?q=node/44&software=geWorkbench&platform=Windows geWorkbench_v2.4.1_Windows_installer_noJRE.exe] <br />
<br />
[{{SERVER}}/workbench/data/geWorkbench_v2.4.1_Windows_installer_with_JRE6.exe geWorkbench_v2.4.1_Windows_installer_with_JRE6.exe]<br />
<br />
=geWorkbench 2.4.1 - System Requirements=<br />
==Java== <br />
* The Java 6 Runtime Environment (JRE6) is required. geWorkbench will run using Java 7, but has not been tested extensively in that environment. Several incompatibilities have already been seen under Java 7 (see [[Known_Issues|Known Issues]] for details).<br />
* For Windows and Linux, geWorkbench is distributed in two installer forms, one with and one without the JRE6 included. To install a version of geWorkbench that does not include the JRE, the JRE6 must be installed separately on the machine. <br />
* On MacOSX, the Java 6 JRE is included with MacOSX versions 10.5 and higher with the latest updates (Intel platforms only). Java 6 is not available for the PowerPC platform.<br />
* The "Generic" distribution of geWorkbench does not include the JRE6. It must be installed separately.<br />
* geWorkbench can run on both 32-bit and 64-bit versions of Java on appropriate OS platforms.<br />
<br />
<br />
===How to choose===<br />
* Using an installer version of geWorkbench that inludes the JRE6 allows you to be sure that you are running geWorkbench with the correct version of the JRE. <br />
* You may wish to install a "no JRE" version of geWorkbench if you want to choose between 32 and 64 bit JREs, to keep up with the latest updates to the JRE, or to experiment with Java 7.<br />
<br />
===Obtaining the Java 6 JRE===<br />
* The JRE6 can be downloaded from http://www.oracle.com/technetwork/java/javase/downloads<br />
* Note: Java 6 is also referred to as Java 1.6.<br />
<br />
==Display Driver==<br />
* This requirement pertains only to using the PCA component 3D graph viewer.<br />
* When using a 64-bit JVM, the Java 3D library requires that OpenGL version 1.2 or higher be supported by your display driver.<br />
<br />
==Memory== <br />
At least 2 GB is recommended. geWorkbench 2.4.1 by default will request up to 1 GB of memory for the Java VM.<br />
<br />
==Operating System==<br />
* '''Windows XP/Vista/Windows 7 (32 or 64-bit)''': no special requirements.<br />
<br />
* '''MacOSX''': Version 10.5 with latest updates, or any higher version (10.6, 10.7 +) is required to provide the Java 6 JRE (Intel platform only).<br />
<br />
* '''Linux''': A version of Java must already be installed on the machine in order to run the geWorkbench installer.<br />
<br />
geWorkbench, unless otherwise noted for particular components, can be run on both 32 and 64-bit operating systems and JREs.<br />
<br />
==Graphics Driver==<br />
At least one component, the PCA viewer, uses a Java 3D library. When using a 64-bit JVM, the Java 3D library requires OpenGL version 1.2 or higher to be supported by the graphics display adapter in your computer.<br />
<br />
<br />
==R server==<br />
The SAM analysis component can use a local installation of R on your desktop computer.<br />
<br />
This has been tested with R version 2.15.0.<br />
<br />
At least for Windows 7 installations, it may be necessary to have R installed in a user directory rather than in a system directory, e.g. to "c:\users\username\R-2.15.0", where "username" is your own account name.<br />
<br />
=IMPORTANT NOTICE ABOUT THE LICENSE=<br />
Use of geWorkbench is governed by the rules specified in the [[geWorkbench License | software license]]. Please make sure to read the license and understand your obligations before proceeding to download the application.<br />
<br />
<br />
<br />
=Installation Instructions=<br />
<br />
All three platform-specific versions of geWorkbench (Windows, Linux, and Macintosh) provide an installation wizard (generated using InstallAnywhere).<br />
<br />
* Using an installer version of geWorkbench that inludes the JRE6 allows you to be sure that you are running geWorkbench with the correct version of the JRE. <br />
* You may wish to install a "no JRE" version of geWorkbench if you want to choose yourself between 32 and 64 bit JREs, or to keep up with the latest updates to the JRE.<br />
* On Windows and Linux, geWorkbench was tested using installer versions which included the JRE6. The included JREs are 32-bit versions.<br />
<br />
A generic version of geWorkbench, which does not use any installer, is also available, and should run on any machine which supports Java 6.<br />
<br />
Further information about the [http://www.flexerasoftware.com/products/installanywhere/requirements.htm InstallAnywhere requirements] are found at the Flexera website.<br />
<br />
<br />
==Windows (XP/Vista/Windows 7)==<br />
<br />
===Special note for Vista/Windows 7===<br />
If you run the installer on Vista or Windows 7, the installer will prompt you to install geWorkbench to your user home directory, e.g. '''C:\Users\''username''\geWorkbench_2.4.1''', where ''username'' is your Windows login name.<br />
<br />
===Installer with JRE6===<br />
* File: geWorkbench_v2.4.1_Windows_installer_with_JRE6.exe<br />
* Includes the 32-bit Sun Java 6 JRE.<br />
<br />
Download and double-click the installer file to begin installation.<br />
<br />
===Installer without JRE6=== <br />
* File: geWorkbench_v2.4.1_Windows_installer_noJRE.exe<br />
* No JRE is included, you must make sure that an appropriate Java 6 JRE is installed on your system before installing geWorkbench.<br />
<br />
Download and double-click the installer file to begin installation.<br />
<br />
==MacOSX==<br />
<br />
* File: geWorkbench_v2.4.1_MacOSX_installer.zip.<br />
* This version uses the Java 6 JRE included with recent updates to the MacOSX operating system. (Intel platforms only).<br />
<br />
Double-click geWorkbench_v2.4.1_MacOSX_installer.zip to begin installation. This will extract a file called "install". Double-click on this file to install geWorkbench.<br />
<br />
===Notes===<br />
* Requires Mac OS X 10.5 with recent updates, or 10.6 or 10.7+.<br />
* As Java 6 is not available for the PowerPC platform, regardless of OS X version, geworkbench will not run on the PowerPC platform under any version of OS X.<br />
* The compressed installer should be expanded automatically by the system.<br />
<br />
==Linux==<br />
<br />
===Installer with JRE6=== <br />
* File: geWorkbench_v2.4.1_Linux_installer_with_JRE6.bin.<br />
* Includes the 32-bit Sun Java 6 JRE.<br />
<br />
===Installer without JRE6=== <br />
* File: geWorkbench_v2.4.1_Linux_installer_noJRE.bin.<br />
* No JRE is included, you must make sure that an appropriate Java 6 JRE is installed on your system before installing geWorkbench.<br />
* You may need to configure the JRE. See section below, "Java Environment Configuration".<br />
<br />
===Installation===<br />
You must already have installed a version of Java 1.6 or later on your Linux machine in order to run the geWorkbench installer.<br />
<br />
The Linux version of geWorkbench relies on X-Windows being installed and running. If you are running Linux on a server and e.g. you wish to view the application on a Windows desktop, you will also need to run an X-windows server on your desktop machine. See X-Windows configuration instructions below.<br />
<br />
After downloading, cd (if needed) to the directory to which you downloaded the installer.<br />
<br />
To begin the installation, type the command for the particular version, e.g. for the installer with JRE: <br />
<br />
"sh ./geWorkbench_v2.4.1_Linux_installer_with_JRE6.bin".<br />
<br />
This will extract geWorkbench into a new directory called geWorkbench_2.4.1.<br />
<br />
<br />
If you requested that a desktop link be created, it will be called rungeWorkbench_2.4.1.<br />
<br />
Note - if you made changes to the default installation directory name, the shortcut link may just be called "geWorkbench_2.4.1" rather than "rungeWorkbench_2.4.1".<br />
<br />
===Running geWorkbench (Linux)===<br />
To run geWorkbench, and assuming you are using the Linux bash shell, and that you created a shortcut link during installation, issue one of the following commands from your home directory: <br />
<br />
./rungeWorkbench_2.4.1 <br />
or<br />
sh rungeWorkbench_2.4.1.<br />
or<br />
sh geWorkbench_2.4.1 if the link received the alternative name (see above).<br />
<br />
Alternatively, in the directory in which geWorkbench was installed, you can start geWorkbench with the command:<br />
<br />
sh launch_geWorkbench.sh<br />
<br />
==Generic==<br />
A non-installer-based version of geWorkbench is supplied in a Zip file which should work on any platform.<br />
<br />
File: geWorkbench_v2.4.1_Generic.zip<br />
<br />
===Installation=== <br />
<br />
Unzip the file. It will create a directory geWorkbench_2.4.1.<br />
<br />
<br />
===Running geWorkbench (generic)===<br />
<br />
You must have the Java 6 JRE installed and the JRE must be in the path for geWorkbench (see Java Environment Configuration below).<br />
<br />
Windows: you can double click on the file "launch_geWorkbench.bat" to launch geWorkbench, or run it from a command window.<br />
<br />
Linux/Unix: Execute the script "launch_geworkbench.sh".<br />
<br />
Any: Alternatively, if you have Apache Ant installed, you can type "ant run" in the geWorkbench directory.<br />
<br />
=Java Environment Configuration=<br />
<br />
To run a version of geWorkbench that does not include the Java 6 Runtime Environment (JRE6), the JRE6 must be installed and, depending on the platform configured separately.<br />
<br />
Two environment variables may need to be properly configured. These are the JAVA_HOME and the PATH variables. They should be configured to point to your own installation of the JRE6. <br />
<br />
Here is an example of setting the two environment variables for a JRE installed in the directory /opt:<br />
<br />
JAVA_HOME=/opt/jre1.6.0_31<br />
<br />
PATH=/opt/jre1.6.0_31/bin:$PATH<br />
<br />
=Typical steps in running X-windows=<br />
Here are some typical steps to configure a remote Linux host and a local desktop X-server. Under Windows, a local X-server can be provided for example by the Cygwin package.<br />
<br />
On the remote Linux host (assuming you are using the bash shell), issue the command<br />
* "export DISPLAY=(your IP):0"<br />
where (your IP) should be substituted with the IP address of your local desktop machine.<br />
<br />
On your local desktop machine, you may need to<br />
# start the X-windows server with a command such as "startx". You may need to cd to the X11 bin directory to find this command.<br />
# allow remote connections with a command such as "xhost +".<br />
<br />
=Quick Start=<br />
A [[QuickStart| Quick Start]] guide to geWorkbench is being developed.<br />
<br />
=Community Support Forums=<br />
geWorkbench community forums are operated by the caBIG Molecular Analysis Tools Knowledge Center. There are separate user and developer forums. Anyone can browse through existing postings, but to start a new topic one must first register.<br />
<br />
The forums can be viewed at https://cabig-kc.nci.nih.gov/Molecular/forums/<br />
<br />
<br />
=Tutorial data=<br />
<br />
[[Media:tutorial_data.zip|tutorial_data.zip]] (3.586 MB) - data files in several different formats useful for the tutorials or just trying out geWorkbench.<br />
<br />
[[Media:Bcell-100.zip|Bcell-100.zip]] (5.256 MB) - A large (100 array) microarray dataset in the geWorkbench matrix format. Data is from the lab of Riccardo Dalla-Favera, Columbia University, and is provided only for use in learning and testing geWorkbench. It was obtained from experiments using Affymetrix HG-U95Av2 chips. This file contains the same data as the previously used file "webmatrix", but with the array subsets given more descriptive names.<br />
<br />
<br />
=Training Slides=<br />
A set of PowerPoint training slides for an earlier version of geWorkbench is still available, but is of historical interest only. The PowerPoint file is available from the [[Project Documentation]] section of this site.</div>Zjihttp://wiki.c2b2.columbia.edu/workbench/index.php?title=Style_Guide&diff=9729Style Guide2012-03-01T18:58:19Z<p>Zji: /* geWorkbench Developer Style Guide */</p>
<hr />
<div>== geWorkbench Developer Style Guide ==<br />
<br />
There are various good style guides out there on the Internet, this document is meant to focus on the issues that are more relevant to the current code base and development activity of geWorkbench. While it is not practical to enforce the style over the legacy code, new development should follow the guide line described here. Any [mailto:zji@c2b2.columbia.edu comments] are very welcome.<br />
* Remove dead code. This includes: unused local variables, unused private members, unused public members, out-of-date comments, unused classes/files, unless you have specific reason to expect to use it soon or as part of unfinished development.<br />
* If a local variable is adequate to serve your purpose, do not make it a member variable.<br />
* If a private member serves your purpose, do not make it public or default or protected.<br />
* If the class is not intended to be extended, declare it as final - unless those require by geWorkbench framework not to be final.<br />
* If the method parameter is intended to be read only, declare it as final.<br />
* Name classes, variables, and methods what they really are or really do. If you cannot name your class as a noun, something is wrong with your design; if you cannot name your method as a verb, something is wrong with your design.<br />
* If one java file is over 1000 lines, the design deserves very careful scrutiny.<br />
* If class A refers to class B, and at the same time class B refers class A, the design needs scrutiny.<br />
* Refer to the object by a proper interface instead of implementation class when possible.<br />
* Immutable class is preferred. Particularly, do NOT implement setters for your class if you are not sure why it is necessary.<br />
* Clean up and organize imports to avoid unnecessary building dependency and to make dependency more explicit: (ctrl+shift+o in eclipse)<br />
* Format code (ctrl+shift+o in eclipse, unless it makes it hard to keep track of the changes)<br />
<br />
=== Project Structure ===<br />
This section describes the directory structure of the project. The root directory structure contains eclipse project file, the <tt>java.policy</tt> file, the <tt>build.xml</tt> ant build file, and the following subdirectories besides other contents:<br />
* <tt>_all</tt> - out of date stuff - to be removed.<br />
* <tt>components</tt> - The top-level directory for geWorkbench components.<br />
* <tt>data</tt> - Sample data files for the project.<br />
* <tt>lib</tt> - Library files for core geWorkbench.<br />
* <tt>src</tt> - Source code for core geWorkbench.<br />
<br />
Each component is in a subdirectory of the <tt>components</tt> directory. It contains an eclipse project file and its directory structure is as follows:<br />
* <tt>lib</tt> - Library files depended on by this component.<br />
* <tt>src</tt> - Source code for the component.<br />
<br />
Note that the components can depend on the core classes (those defined in <tt>./src</tt>) and the core libraries (those defined in <tt>./lib</tt>). However, components cannot depend on each other, and the core classes cannot depend on components.<br />
<br />
=== Creating a New Component ===<br />
A new component should be added as a new subdirectory of <tt>components</tt>. The subdirectory should be given a simple, descriptive, lower-case name. It should contain <tt>src</tt> and <tt>lib</tt> directories. Most importantly, the component must not depend on the classes or libraries of any other component, nor should another component depend on it. Also, the core geWorkbench classes should not depend on its classes or libraries.<br />
<br />
=== Coding Standards ===<br />
The [http://java.sun.com/docs/codeconv/html/CodeConvTOC.doc.html coding standards] outlined by Sun are observed.<br />
Here are some of rules that are particularly important to us:<br />
==== Capitalization ====<br />
Constants must be in all-capitals, with underscores between words:<br />
public static final int MAXIMUM_FILES = 100;<br />
<b>No</b> other identifiers may contain underscores but constants.<br />
Class, interface, enum and annotation names must be capitalized, with all subsequent words also capitalized:<br />
public class SampleClass extends AnotherSampleClass {<br />
Variable and member names must have their first letter lower-case, and subsequent words capitalized:<br />
private String fieldName;<br />
<br />
private abstract void processFile(File file);<br />
Some developers differentiate between method variables and class members by prepending <tt>m_</tt> or just <tt>_</tt> to member names.<br />
This is not a standard practice, so is not observed. Identifiers in property files are all lower-case with periods separating words:<br />
maximum.files=100<br />
Type wildcards in generics must be a single capital letter:<br />
public interface Generic&lt;T, S extends Serializable&gt; {<br />
==== Annotations ====<br />
Annotations can either appear on the same line as their associated declaration, or on the line before it:<br />
@Subscribe public void receive(Integer value) {<br />
<br />
@Script(dependencies = {STATE_UNINITIALIZED, STATE_COMPLETE}, result = STATE_INITIALIZED)<br />
public void initialize() {<br />
==== Variable Naming ====<br />
Variables should be given verbose names, even if they are only used in relatively small code blocks. Using the auto-complete functionality of modern IDEs makes compliance with this rule painless. Exceptions are simple index variables, such as those introduced in <code>for(;;)</code> statements:<br />
for (int i = 0; i < 100; i++) {<br />
==== Braces ====<br />
All <tt>if</tt>, <tt>while</tt> and similar block structures must be surrounded by braces, even if the body of the block consists of only one statement:<br />
if (index < 100) {<br />
System.out.println("index= " + index);<br />
}<br />
==== No Shortcuts ====<br />
Java provides some C-style shortcuts, such as the <code>++</code>, <code>+=</code> and <code>?:</code> operators. The <code>++</code>, <code>+=</code> operators can be used by themselves (for example, <code>++</code> is often used in a <code>for</code> statement) but they should not be included in other statements. The <code>?:</code> operator should only be used very sparingly, usually in statements that construct strings. Here is an example of a <b>bad</b> use of <code>++</code>:<br />
while (i < 100) {<br />
System.out.println("i= " + i++);<br />
}<br />
This is preferred:<br />
while (i < 100) {<br />
System.out.println("i= " + i);<br />
i++;<br />
}<br />
This is an acceptable use of <code>?:</code>:<br />
boolean available;<br />
...<br />
System.out.println("The file is " + (available ? "available" : "unavailable") + ".");<br />
However, it is a safe bet to never use <code>?:</code>.<br />
==== Tabs ====<br />
A tab-width of 4 should be used.<br />
<br />
=== Code Documentation ===<br />
Code must be documented using the [http://java.sun.com/j2se/javadoc/ Javadoc] standard.<br />
All classes, interfaces, enums and annotations must have an introductory Javadoc explaining its purpose.<br />
All public methods must also have explanatory Javadocs.<br />
Methods that perform non-trivial operations should have normal comments (not Javadoc) that explain the code.<br />
Such comments should precede the line (or lines) of code that they describe.<br />
For example:<br />
/**<br />
* Shuts down the componentRegistry (and terminates any pending aysnchronous dispatches).<br />
*/<br />
public void shutdown() {<br />
// Iterate through all active synch models<br />
Collection&lt;SynchModel&gt; models = synchModels.values();<br />
for (SynchModel synchModel : models) {<br />
// Shut down the synch model<br />
synchModel.shutdown();<br />
}<br />
}<br />
=== Packages ===<br />
Package names should follow the inverse-domain rule. If the domain of your organization is<br />
<code>subdomain.domain.tld</code>, then the package structure should be rooted at <code>tld.domain.subdomain</code>.<br />
Capital letters or underscore characters should never appear in package names.<br />
<br />
Otherwise, the organization of packages is left up to the developer.</div>Zjihttp://wiki.c2b2.columbia.edu/workbench/index.php?title=Style_Guide&diff=9728Style Guide2012-03-01T18:50:28Z<p>Zji: /* geWorkbench Developer Style Guide */</p>
<hr />
<div>== geWorkbench Developer Style Guide ==<br />
This document provides a style guide for developers of geWorkbench. The old content that has not been updated since 2005 may include something useful, so I keep them for now at the end the page, titled "Old Content".<br />
<br />
There are various good style guides out there on the Internet, this document is meant to focus on the issues that are more relevant to the current code base and development activity of geWorkbench. While it is not practical to enforce the style over the legacy code, new development should follow the guide line described here. Any [mailto:zji@c2b2.columbia.edu comments] are very welcome.<br />
* Remove dead code. This includes: unused local variables, unused private members, unused public members, out-of-date comments, unused classes/files, unless you have specific reason to expect to use it soon or as part of unfinished development.<br />
* If a local variable is adequate to serve your purpose, do not make it a member variable.<br />
* If a private member serves your purpose, do not make it public or default or protected.<br />
* If the class is not intended to be extended, declare it as final - unless those require by geWorkbench framework not to be final.<br />
* If the method parameter is intended to be read only, declare it as final.<br />
* Name classes, variables, and methods what they really are or really do. If you cannot name your class as a noun, something is wrong with your design; if you cannot name your method as a verb, something is wrong with your design.<br />
* If one java file is over 1000 lines, the design deserves very careful scrutiny.<br />
* If class A refers to class B, and at the same time class B refers class A, the design needs scrutiny.<br />
* Refer to the object by a proper interface instead of implementation class when possible.<br />
* Immutable class is preferred. Particularly, do NOT implement setters for your class if you are not sure why it is necessary.<br />
* Clean up and organize imports to avoid unnecessary building dependency and to make dependency more explicit: (ctrl+shift+o in eclipse)<br />
* Format code (ctrl+shift+o in eclipse, unless it makes it hard to keep track of the changes)<br />
<br />
=== Project Structure ===<br />
This section describes the directory structure of the project. The root directory structure contains eclipse project file, the <tt>java.policy</tt> file, the <tt>build.xml</tt> ant build file, and the following subdirectories besides other contents:<br />
* <tt>_all</tt> - out of date stuff - to be removed.<br />
* <tt>components</tt> - The top-level directory for geWorkbench components.<br />
* <tt>data</tt> - Sample data files for the project.<br />
* <tt>lib</tt> - Library files for core geWorkbench.<br />
* <tt>src</tt> - Source code for core geWorkbench.<br />
<br />
Each component is in a subdirectory of the <tt>components</tt> directory. It contains an eclipse project file and its directory structure is as follows:<br />
* <tt>lib</tt> - Library files depended on by this component.<br />
* <tt>src</tt> - Source code for the component.<br />
<br />
Note that the components can depend on the core classes (those defined in <tt>./src</tt>) and the core libraries (those defined in <tt>./lib</tt>). However, components cannot depend on each other, and the core classes cannot depend on components.<br />
<br />
=== Creating a New Component ===<br />
A new component should be added as a new subdirectory of <tt>components</tt>. The subdirectory should be given a simple, descriptive, lower-case name. It should contain <tt>src</tt> and <tt>lib</tt> directories. Most importantly, the component must not depend on the classes or libraries of any other component, nor should another component depend on it. Also, the core geWorkbench classes should not depend on its classes or libraries.<br />
<br />
=== Coding Standards ===<br />
The [http://java.sun.com/docs/codeconv/html/CodeConvTOC.doc.html coding standards] outlined by Sun are observed.<br />
Here are some of rules that are particularly important to us:<br />
==== Capitalization ====<br />
Constants must be in all-capitals, with underscores between words:<br />
public static final int MAXIMUM_FILES = 100;<br />
<b>No</b> other identifiers may contain underscores but constants.<br />
Class, interface, enum and annotation names must be capitalized, with all subsequent words also capitalized:<br />
public class SampleClass extends AnotherSampleClass {<br />
Variable and member names must have their first letter lower-case, and subsequent words capitalized:<br />
private String fieldName;<br />
<br />
private abstract void processFile(File file);<br />
Some developers differentiate between method variables and class members by prepending <tt>m_</tt> or just <tt>_</tt> to member names.<br />
This is not a standard practice, so is not observed. Identifiers in property files are all lower-case with periods separating words:<br />
maximum.files=100<br />
Type wildcards in generics must be a single capital letter:<br />
public interface Generic&lt;T, S extends Serializable&gt; {<br />
==== Annotations ====<br />
Annotations can either appear on the same line as their associated declaration, or on the line before it:<br />
@Subscribe public void receive(Integer value) {<br />
<br />
@Script(dependencies = {STATE_UNINITIALIZED, STATE_COMPLETE}, result = STATE_INITIALIZED)<br />
public void initialize() {<br />
==== Variable Naming ====<br />
Variables should be given verbose names, even if they are only used in relatively small code blocks. Using the auto-complete functionality of modern IDEs makes compliance with this rule painless. Exceptions are simple index variables, such as those introduced in <code>for(;;)</code> statements:<br />
for (int i = 0; i < 100; i++) {<br />
==== Braces ====<br />
All <tt>if</tt>, <tt>while</tt> and similar block structures must be surrounded by braces, even if the body of the block consists of only one statement:<br />
if (index < 100) {<br />
System.out.println("index= " + index);<br />
}<br />
==== No Shortcuts ====<br />
Java provides some C-style shortcuts, such as the <code>++</code>, <code>+=</code> and <code>?:</code> operators. The <code>++</code>, <code>+=</code> operators can be used by themselves (for example, <code>++</code> is often used in a <code>for</code> statement) but they should not be included in other statements. The <code>?:</code> operator should only be used very sparingly, usually in statements that construct strings. Here is an example of a <b>bad</b> use of <code>++</code>:<br />
while (i < 100) {<br />
System.out.println("i= " + i++);<br />
}<br />
This is preferred:<br />
while (i < 100) {<br />
System.out.println("i= " + i);<br />
i++;<br />
}<br />
This is an acceptable use of <code>?:</code>:<br />
boolean available;<br />
...<br />
System.out.println("The file is " + (available ? "available" : "unavailable") + ".");<br />
However, it is a safe bet to never use <code>?:</code>.<br />
==== Tabs ====<br />
A tab-width of 4 should be used.<br />
<br />
=== Code Documentation ===<br />
Code must be documented using the [http://java.sun.com/j2se/javadoc/ Javadoc] standard.<br />
All classes, interfaces, enums and annotations must have an introductory Javadoc explaining its purpose.<br />
All public methods must also have explanatory Javadocs.<br />
Methods that perform non-trivial operations should have normal comments (not Javadoc) that explain the code.<br />
Such comments should precede the line (or lines) of code that they describe.<br />
For example:<br />
/**<br />
* Shuts down the componentRegistry (and terminates any pending aysnchronous dispatches).<br />
*/<br />
public void shutdown() {<br />
// Iterate through all active synch models<br />
Collection&lt;SynchModel&gt; models = synchModels.values();<br />
for (SynchModel synchModel : models) {<br />
// Shut down the synch model<br />
synchModel.shutdown();<br />
}<br />
}<br />
=== Packages ===<br />
Package names should follow the inverse-domain rule. If the domain of your organization is<br />
<code>subdomain.domain.tld</code>, then the package structure should be rooted at <code>tld.domain.subdomain</code>.<br />
Capital letters or underscore characters should never appear in package names.<br />
<br />
Otherwise, the organization of packages is left up to the developer.</div>Zjihttp://wiki.c2b2.columbia.edu/workbench/index.php?title=Style_Guide&diff=9706Style Guide2012-03-01T17:01:56Z<p>Zji: /* geWorkbench Code Organization Standard */</p>
<hr />
<div>== geWorkbench Developer Style Guide ==<br />
This document provides a style guide for developers of geWorkbench. The old content that has not been updated since 2005 may include something useful, so I keep them for now at the end the page, titled "Old Content".<br />
<br />
There are various good style guides out there on the Internet, this document is meant to focus on the issues that are more relevant to the current code base and development activity of geWorkbench. While it is not practical to enforce the style over the legacy code, new development should follow the guide line described here. Any [mailto:zji@c2b2.columbia.edu comments] are very welcome.<br />
* Remove dead code. This includes: unused local variables, unused private members, unused public members, out-of-date comments, unused classes/files, unless you have specific reason to expect to use it soon or as part of unfinished development.<br />
* If a local variable is adequate to serve your purpose, do not make it a member variable.<br />
* If a private member serves your purpose, do not make it public or default or protected.<br />
* If the class is not intended to be extended, declare it as final - unless those require by geWorkbench framework not to be final.<br />
* If the method parameter is intended to be read only, declare it as final.<br />
* Name classes, variables, and methods what they really are or really do. If you cannot name your class as a noun, something is wrong with your design; if you cannot name your method as a verb, something is wrong with your design.<br />
* If one java file is over 1000 lines, the design deserves very careful scrutiny.<br />
* If class A refers to class B, and at the same time class B refers class A, the design needs scrutiny.<br />
* Refer to the object by a proper interface instead of implementation class when possible.<br />
* Immutable class is preferred. Particularly, do NOT implement setters for your class if you are not sure why it is necessary.<br />
<br />
=== Project Structure ===<br />
This section describes the directory structure of the project. The root directory structure contains eclipse project file, the <tt>java.policy</tt> file, the <tt>build.xml</tt> ant build file, and the following subdirectories besides other contents:<br />
* <tt>_all</tt> - out of date stuff - to be removed.<br />
* <tt>components</tt> - The top-level directory for geWorkbench components.<br />
* <tt>data</tt> - Sample data files for the project.<br />
* <tt>lib</tt> - Library files for core geWorkbench.<br />
* <tt>src</tt> - Source code for core geWorkbench.<br />
<br />
Each component is in a subdirectory of the <tt>components</tt> directory. It contains an eclipse project file and its directory structure is as follows:<br />
* <tt>lib</tt> - Library files depended on by this component.<br />
* <tt>src</tt> - Source code for the component.<br />
<br />
Note that the components can depend on the core classes (those defined in <tt>./src</tt>) and the core libraries (those defined in <tt>./lib</tt>). However, components cannot depend on each other, and the core classes cannot depend on components.<br />
<br />
=== Creating a New Component ===<br />
A new component should be added as a new subdirectory of <tt>components</tt>. The subdirectory should be given a simple, descriptive, lower-case name. It should contain <tt>src</tt> and <tt>lib</tt> directories. Most importantly, the component must not depend on the classes or libraries of any other component, nor should another component depend on it. Also, the core geWorkbench classes should not depend on its classes or libraries.<br />
<br />
=== Coding Standards ===<br />
The [http://java.sun.com/docs/codeconv/html/CodeConvTOC.doc.html coding standards] outlined by Sun are observed.<br />
Here are some of rules that are particularly important to us:<br />
==== Capitalization ====<br />
Constants must be in all-capitals, with underscores between words:<br />
public static final int MAXIMUM_FILES = 100;<br />
<b>No</b> other identifiers may contain underscores but constants.<br />
Class, interface, enum and annotation names must be capitalized, with all subsequent words also capitalized:<br />
public class SampleClass extends AnotherSampleClass {<br />
Variable and member names must have their first letter lower-case, and subsequent words capitalized:<br />
private String fieldName;<br />
<br />
private abstract void processFile(File file);<br />
Some developers differentiate between method variables and class members by prepending <tt>m_</tt> or just <tt>_</tt> to member names.<br />
This is not a standard practice, so is not observed. Identifiers in property files are all lower-case with periods separating words:<br />
maximum.files=100<br />
Type wildcards in generics must be a single capital letter:<br />
public interface Generic&lt;T, S extends Serializable&gt; {<br />
==== Annotations ====<br />
Annotations can either appear on the same line as their associated declaration, or on the line before it:<br />
@Subscribe public void receive(Integer value) {<br />
<br />
@Script(dependencies = {STATE_UNINITIALIZED, STATE_COMPLETE}, result = STATE_INITIALIZED)<br />
public void initialize() {<br />
==== Variable Naming ====<br />
Variables should be given verbose names, even if they are only used in relatively small code blocks. Using the auto-complete functionality of modern IDEs makes compliance with this rule painless. Exceptions are simple index variables, such as those introduced in <code>for(;;)</code> statements:<br />
for (int i = 0; i < 100; i++) {<br />
==== Braces ====<br />
All <tt>if</tt>, <tt>while</tt> and similar block structures must be surrounded by braces, even if the body of the block consists of only one statement:<br />
if (index < 100) {<br />
System.out.println("index= " + index);<br />
}<br />
==== No Shortcuts ====<br />
Java provides some C-style shortcuts, such as the <code>++</code>, <code>+=</code> and <code>?:</code> operators. The <code>++</code>, <code>+=</code> operators can be used by themselves (for example, <code>++</code> is often used in a <code>for</code> statement) but they should not be included in other statements. The <code>?:</code> operator should only be used very sparingly, usually in statements that construct strings. Here is an example of a <b>bad</b> use of <code>++</code>:<br />
while (i < 100) {<br />
System.out.println("i= " + i++);<br />
}<br />
This is preferred:<br />
while (i < 100) {<br />
System.out.println("i= " + i);<br />
i++;<br />
}<br />
This is an acceptable use of <code>?:</code>:<br />
boolean available;<br />
...<br />
System.out.println("The file is " + (available ? "available" : "unavailable") + ".");<br />
However, it is a safe bet to never use <code>?:</code>.<br />
==== Tabs ====<br />
A tab-width of 4 should be used.<br />
<br />
=== Code Documentation ===<br />
Code must be documented using the [http://java.sun.com/j2se/javadoc/ Javadoc] standard.<br />
All classes, interfaces, enums and annotations must have an introductory Javadoc explaining its purpose.<br />
All public methods must also have explanatory Javadocs.<br />
Methods that perform non-trivial operations should have normal comments (not Javadoc) that explain the code.<br />
Such comments should precede the line (or lines) of code that they describe.<br />
For example:<br />
/**<br />
* Shuts down the componentRegistry (and terminates any pending aysnchronous dispatches).<br />
*/<br />
public void shutdown() {<br />
// Iterate through all active synch models<br />
Collection&lt;SynchModel&gt; models = synchModels.values();<br />
for (SynchModel synchModel : models) {<br />
// Shut down the synch model<br />
synchModel.shutdown();<br />
}<br />
}<br />
=== Packages ===<br />
Package names should follow the inverse-domain rule. If the domain of your organization is<br />
<code>subdomain.domain.tld</code>, then the package structure should be rooted at <code>tld.domain.subdomain</code>.<br />
Capital letters or underscore characters should never appear in package names.<br />
<br />
Otherwise, the organization of packages is left up to the developer.</div>Zjihttp://wiki.c2b2.columbia.edu/workbench/index.php?title=Style_Guide&diff=9705Style Guide2012-03-01T16:57:16Z<p>Zji: /* Coding Style */</p>
<hr />
<div>== geWorkbench Developer Style Guide ==<br />
This document provides a style guide for developers of geWorkbench. The old content that has not been updated since 2005 may include something useful, so I keep them for now at the end the page, titled "Old Content".<br />
<br />
There are various good style guides out there on the Internet, this document is meant to focus on the issues that are more relevant to the current code base and development activity of geWorkbench. While it is not practical to enforce the style over the legacy code, new development should follow the guide line described here. Any [mailto:zji@c2b2.columbia.edu comments] are very welcome.<br />
* Remove dead code. This includes: unused local variables, unused private members, unused public members, out-of-date comments, unused classes/files, unless you have specific reason to expect to use it soon or as part of unfinished development.<br />
* If a local variable is adequate to serve your purpose, do not make it a member variable.<br />
* If a private member serves your purpose, do not make it public or default or protected.<br />
* If the class is not intended to be extended, declare it as final - unless those require by geWorkbench framework not to be final.<br />
* If the method parameter is intended to be read only, declare it as final.<br />
* Name classes, variables, and methods what they really are or really do. If you cannot name your class as a noun, something is wrong with your design; if you cannot name your method as a verb, something is wrong with your design.<br />
* If one java file is over 1000 lines, the design deserves very careful scrutiny.<br />
* If class A refers to class B, and at the same time class B refers class A, the design needs scrutiny.<br />
* Refer to the object by a proper interface instead of implementation class when possible.<br />
* Immutable class is preferred. Particularly, do NOT implement setters for your class if you are not sure why it is necessary.<br />
<br />
=== Project Structure ===<br />
This section describes the directory structure of the project. The root directory structure contains eclipse project file, the <tt>java.policy</tt> file, the <tt>build.xml</tt> ant build file, and the following subdirectories besides other contents:<br />
* <tt>_all</tt> - out of date stuff - to be removed.<br />
* <tt>components</tt> - The top-level directory for geWorkbench components.<br />
* <tt>data</tt> - Sample data files for the project.<br />
* <tt>lib</tt> - Library files for core geWorkbench.<br />
* <tt>src</tt> - Source code for core geWorkbench.<br />
<br />
Each component is in a subdirectory of the <tt>components</tt> directory. It contains an eclipse project file and its directory structure is as follows:<br />
* <tt>lib</tt> - Library files depended on by this component.<br />
* <tt>src</tt> - Source code for the component.<br />
<br />
Note that the components can depend on the core classes (those defined in <tt>./src</tt>) and the core libraries (those defined in <tt>./lib</tt>). However, components cannot depend on each other, and the core classes cannot depend on components.<br />
<br />
=== Creating a New Component ===<br />
A new component should be added as a new subdirectory of <tt>components</tt>. The subdirectory should be given a simple, descriptive, lower-case name. It should contain <tt>src</tt> and <tt>lib</tt> directories. Most importantly, the component must not depend on the classes or libraries of any other component, nor should another component depend on it. Also, the core geWorkbench classes should not depend on its classes or libraries.<br />
<br />
== geWorkbench Code Organization Standard==<br />
<br />
=== Old Content ===<br />
<br />
<br />
=== Coding Standards ===<br />
The [http://java.sun.com/docs/codeconv/html/CodeConvTOC.doc.html coding standards] outlined by Sun are observed.<br />
Here are some of rules that are particularly important to us:<br />
===== Capitalization =====<br />
Constants must be in all-capitals, with underscores between words:<br />
public static final int MAXIMUM_FILES = 100;<br />
<b>No</b> other identifiers may contain underscores but constants.<br />
Class, interface, enum and annotation names must be capitalized, with all subsequent words also capitalized:<br />
public class SampleClass extends AnotherSampleClass {<br />
Variable and member names must have their first letter lower-case, and subsequent words capitalized:<br />
private String fieldName;<br />
<br />
private abstract void processFile(File file);<br />
Some developers differentiate between method variables and class members by prepending <tt>m_</tt> or just <tt>_</tt> to member names.<br />
This is not a standard practice, so is not observed. Identifiers in property files are all lower-case with periods separating words:<br />
maximum.files=100<br />
Type wildcards in generics must be a single capital letter:<br />
public interface Generic&lt;T, S extends Serializable&gt; {<br />
==== Annotations ====<br />
Annotations can either appear on the same line as their associated declaration, or on the line before it:<br />
@Subscribe public void receive(Integer value) {<br />
<br />
@Script(dependencies = {STATE_UNINITIALIZED, STATE_COMPLETE}, result = STATE_INITIALIZED)<br />
public void initialize() {<br />
==== Variable Naming ====<br />
Variables should be given verbose names, even if they are only used in relatively small code blocks. Using the auto-complete functionality of modern IDEs makes compliance with this rule painless. Exceptions are simple index variables, such as those introduced in <code>for(;;)</code> statements:<br />
for (int i = 0; i < 100; i++) {<br />
==== Braces ====<br />
All <tt>if</tt>, <tt>while</tt> and similar block structures must be surrounded by braces, even if the body of the block consists of only one statement:<br />
if (index < 100) {<br />
System.out.println("index= " + index);<br />
}<br />
==== No Shortcuts ====<br />
Java provides some C-style shortcuts, such as the <code>++</code>, <code>+=</code> and <code>?:</code> operators. The <code>++</code>, <code>+=</code> operators can be used by themselves (for example, <code>++</code> is often used in a <code>for</code> statement) but they should not be included in other statements. The <code>?:</code> operator should only be used very sparingly, usually in statements that construct strings. Here is an example of a <b>bad</b> use of <code>++</code>:<br />
while (i < 100) {<br />
System.out.println("i= " + i++);<br />
}<br />
This is preferred:<br />
while (i < 100) {<br />
System.out.println("i= " + i);<br />
i++;<br />
}<br />
This is an acceptable use of <code>?:</code>:<br />
boolean available;<br />
...<br />
System.out.println("The file is " + (available ? "available" : "unavailable") + ".");<br />
However, it is a safe bet to never use <code>?:</code>.<br />
==== Tabs ====<br />
A tab-width of 4 should be used.<br />
<br />
=== Code Documentation ===<br />
Code must be documented using the [http://java.sun.com/j2se/javadoc/ Javadoc] standard.<br />
All classes, interfaces, enums and annotations must have an introductory Javadoc explaining its purpose.<br />
All public methods must also have explanatory Javadocs.<br />
Methods that perform non-trivial operations should have normal comments (not Javadoc) that explain the code.<br />
Such comments should precede the line (or lines) of code that they describe.<br />
For example:<br />
/**<br />
* Shuts down the componentRegistry (and terminates any pending aysnchronous dispatches).<br />
*/<br />
public void shutdown() {<br />
// Iterate through all active synch models<br />
Collection&lt;SynchModel&gt; models = synchModels.values();<br />
for (SynchModel synchModel : models) {<br />
// Shut down the synch model<br />
synchModel.shutdown();<br />
}<br />
}<br />
=== Packages ===<br />
Package names should follow the inverse-domain rule. If the domain of your organization is<br />
<code>subdomain.domain.tld</code>, then the package structure should be rooted at <code>tld.domain.subdomain</code>.<br />
Capital letters or underscore characters should never appear in package names.<br />
<br />
Otherwise, the organization of packages is left up to the developer.</div>Zjihttp://wiki.c2b2.columbia.edu/workbench/index.php?title=Style_Guide&diff=9704Style Guide2012-03-01T16:54:57Z<p>Zji: /* geWorkbench Code Organization Standard */</p>
<hr />
<div>== geWorkbench Developer Style Guide ==<br />
This document provides a style guide for developers of geWorkbench. The old content that has not been updated since 2005 may include something useful, so I keep them for now at the end the page, titled "Old Content".<br />
<br />
There are various good style guides out there on the Internet, this document is meant to focus on the issues that are more relevant to the current code base and development activity of geWorkbench. While it is not practical to enforce the style over the legacy code, new development should follow the guide line described here. Any [mailto:zji@c2b2.columbia.edu comments] are very welcome.<br />
* Remove dead code. This includes: unused local variables, unused private members, unused public members, out-of-date comments, unused classes/files, unless you have specific reason to expect to use it soon or as part of unfinished development.<br />
* If a local variable is adequate to serve your purpose, do not make it a member variable.<br />
* If a private member serves your purpose, do not make it public or default or protected.<br />
* If the class is not intended to be extended, declare it as final - unless those require by geWorkbench framework not to be final.<br />
* If the method parameter is intended to be read only, declare it as final.<br />
* Name classes, variables, and methods what they really are or really do. If you cannot name your class as a noun, something is wrong with your design; if you cannot name your method as a verb, something is wrong with your design.<br />
* If one java file is over 1000 lines, the design deserves very careful scrutiny.<br />
* If class A refers to class B, and at the same time class B refers class A, the design needs scrutiny.<br />
* Refer to the object by a proper interface instead of implementation class when possible.<br />
* Immutable class is preferred. Particularly, do NOT implement setters for your class if you are not sure why it is necessary.<br />
<br />
=== Project Structure ===<br />
This section describes the directory structure of the project. The root directory structure contains eclipse project file, the <tt>java.policy</tt> file, the <tt>build.xml</tt> ant build file, and the following subdirectories besides other contents:<br />
* <tt>_all</tt> - out of date stuff - to be removed.<br />
* <tt>components</tt> - The top-level directory for geWorkbench components.<br />
* <tt>data</tt> - Sample data files for the project.<br />
* <tt>lib</tt> - Library files for core geWorkbench.<br />
* <tt>src</tt> - Source code for core geWorkbench.<br />
<br />
Each component is in a subdirectory of the <tt>components</tt> directory. It contains an eclipse project file and its directory structure is as follows:<br />
* <tt>lib</tt> - Library files depended on by this component.<br />
* <tt>src</tt> - Source code for the component.<br />
<br />
Note that the components can depend on the core classes (those defined in <tt>./src</tt>) and the core libraries (those defined in <tt>./lib</tt>). However, components cannot depend on each other, and the core classes cannot depend on components.<br />
<br />
=== Creating a New Component ===<br />
A new component should be added as a new subdirectory of <tt>components</tt>. The subdirectory should be given a simple, descriptive, lower-case name. It should contain <tt>src</tt> and <tt>lib</tt> directories. Most importantly, the component must not depend on the classes or libraries of any other component, nor should another component depend on it. Also, the core geWorkbench classes should not depend on its classes or libraries.<br />
<br />
== geWorkbench Code Organization Standard==<br />
<br />
=== Old Content ===<br />
<br />
<br />
=== Coding Style ===<br />
The [http://java.sun.com/docs/codeconv/html/CodeConvTOC.doc.html coding standards] outlined by Sun are observed.<br />
Here are the coding standards that are particularly important to us:<br />
==== Capitalization ====<br />
Constants must be in all-capitals, with underscores between words:<br />
public static final int MAXIMUM_FILES = 100;<br />
<b>No</b> other identifiers may contain underscores but constants.<br />
Class, interface, enum and annotation names must be capitalized, with all subsequent words also capitalized:<br />
public class SampleClass extends AnotherSampleClass {<br />
Variable and member names must have their first letter lower-case, and subsequent words capitalized:<br />
private String fieldName;<br />
<br />
private abstract void processFile(File file);<br />
Some developers differentiate between method variables and class members by prepending <tt>m_</tt> or just <tt>_</tt> to member names.<br />
This is not a standard practice, so is not observed. Identifiers in property files are all lower-case with periods separating words:<br />
maximum.files=100<br />
Type wildcards in generics must be a single capital letter:<br />
public interface Generic&lt;T, S extends Serializable&gt; {<br />
==== Annotations ====<br />
Annotations can either appear on the same line as their associated declaration, or on the line before it:<br />
@Subscribe public void receive(Integer value) {<br />
<br />
@Script(dependencies = {STATE_UNINITIALIZED, STATE_COMPLETE}, result = STATE_INITIALIZED)<br />
public void initialize() {<br />
==== Variable Naming ====<br />
Variables should be given verbose names, even if they are only used in relatively small code blocks. Using the auto-complete functionality of modern IDEs makes compliance with this rule painless. Exceptions are simple index variables, such as those introduced in <code>for(;;)</code> statements:<br />
for (int i = 0; i < 100; i++) {<br />
==== Braces ====<br />
All <tt>if</tt>, <tt>while</tt> and similar block structures must be surrounded by braces, even if the body of the block consists of only one statement:<br />
if (index < 100) {<br />
System.out.println("index= " + index);<br />
}<br />
==== No Shortcuts ====<br />
Java provides some C-style shortcuts, such as the <code>++</code>, <code>+=</code> and <code>?:</code> operators. The <code>++</code>, <code>+=</code> operators can be used by themselves (for example, <code>++</code> is often used in a <code>for</code> statement) but they should not be included in other statements. The <code>?:</code> operator should only be used very sparingly, usually in statements that construct strings. Here is an example of a <b>bad</b> use of <code>++</code>:<br />
while (i < 100) {<br />
System.out.println("i= " + i++);<br />
}<br />
This is preferred:<br />
while (i < 100) {<br />
System.out.println("i= " + i);<br />
i++;<br />
}<br />
This is an acceptable use of <code>?:</code>:<br />
boolean available;<br />
...<br />
System.out.println("The file is " + (available ? "available" : "unavailable") + ".");<br />
However, it is a safe bet to never use <code>?:</code>.<br />
==== Tabs ====<br />
A tab-width of 4 should be used.<br />
<br />
=== Code Documentation ===<br />
Code must be documented using the [http://java.sun.com/j2se/javadoc/ Javadoc] standard.<br />
All classes, interfaces, enums and annotations must have an introductory Javadoc explaining its purpose.<br />
All public methods must also have explanatory Javadocs.<br />
Methods that perform non-trivial operations should have normal comments (not Javadoc) that explain the code.<br />
Such comments should precede the line (or lines) of code that they describe.<br />
For example:<br />
/**<br />
* Shuts down the componentRegistry (and terminates any pending aysnchronous dispatches).<br />
*/<br />
public void shutdown() {<br />
// Iterate through all active synch models<br />
Collection&lt;SynchModel&gt; models = synchModels.values();<br />
for (SynchModel synchModel : models) {<br />
// Shut down the synch model<br />
synchModel.shutdown();<br />
}<br />
}<br />
=== Packages ===<br />
Package names should follow the inverse-domain rule. If the domain of your organization is<br />
<code>subdomain.domain.tld</code>, then the package structure should be rooted at <code>tld.domain.subdomain</code>.<br />
Capital letters or underscore characters should never appear in package names.<br />
<br />
Otherwise, the organization of packages is left up to the developer.</div>Zjihttp://wiki.c2b2.columbia.edu/workbench/index.php?title=Style_Guide&diff=9703Style Guide2012-03-01T16:53:28Z<p>Zji: /* geWorkbench Code Organization Standard */</p>
<hr />
<div>== geWorkbench Developer Style Guide ==<br />
This document provides a style guide for developers of geWorkbench. The old content that has not been updated since 2005 may include something useful, so I keep them for now at the end the page, titled "Old Content".<br />
<br />
There are various good style guides out there on the Internet, this document is meant to focus on the issues that are more relevant to the current code base and development activity of geWorkbench. While it is not practical to enforce the style over the legacy code, new development should follow the guide line described here. Any [mailto:zji@c2b2.columbia.edu comments] are very welcome.<br />
* Remove dead code. This includes: unused local variables, unused private members, unused public members, out-of-date comments, unused classes/files, unless you have specific reason to expect to use it soon or as part of unfinished development.<br />
* If a local variable is adequate to serve your purpose, do not make it a member variable.<br />
* If a private member serves your purpose, do not make it public or default or protected.<br />
* If the class is not intended to be extended, declare it as final - unless those require by geWorkbench framework not to be final.<br />
* If the method parameter is intended to be read only, declare it as final.<br />
* Name classes, variables, and methods what they really are or really do. If you cannot name your class as a noun, something is wrong with your design; if you cannot name your method as a verb, something is wrong with your design.<br />
* If one java file is over 1000 lines, the design deserves very careful scrutiny.<br />
* If class A refers to class B, and at the same time class B refers class A, the design needs scrutiny.<br />
* Refer to the object by a proper interface instead of implementation class when possible.<br />
* Immutable class is preferred. Particularly, do NOT implement setters for your class if you are not sure why it is necessary.<br />
<br />
=== Project Structure ===<br />
This section describes the directory structure of the project. The root directory structure contains eclipse project file, the <tt>java.policy</tt> file, the <tt>build.xml</tt> ant build file, and the following subdirectories besides other contents:<br />
* <tt>_all</tt> - out of date stuff - to be removed.<br />
* <tt>components</tt> - The top-level directory for geWorkbench components.<br />
* <tt>data</tt> - Sample data files for the project.<br />
* <tt>lib</tt> - Library files for core geWorkbench.<br />
* <tt>src</tt> - Source code for core geWorkbench.<br />
<br />
Each component is in a subdirectory of the <tt>components</tt> directory. It contains an eclipse project file and its directory structure is as follows:<br />
* <tt>lib</tt> - Library files depended on by this component.<br />
* <tt>src</tt> - Source code for the component.<br />
<br />
Note that the components can depend on the core classes (those defined in <tt>./src</tt>) and the core libraries (those defined in <tt>./lib</tt>). However, components cannot depend on each other, and the core classes cannot depend on components.<br />
<br />
== geWorkbench Code Organization Standard==<br />
<br />
=== Old Content ===<br />
<br />
=== Creating a New Component ===<br />
A new component should be added as a new subdirectory of <tt>components</tt>. The subdirectory should be given a simple, descriptive, lower-case name. It should contain <tt>src</tt> and <tt>lib</tt> directories. Most importantly, the component must not depend on the classes or libraries of any other component, nor should another component depend on it. Also, the core geWorkbench classes should not depend on its classes or libraries. The <tt>build.xml</tt> will enforce this, as will the IDEA project. However, the JBuilder project currently does not enforce this constraint, so be careful when using JBuilder.<br />
<br />
=== Coding Style ===<br />
The [http://java.sun.com/docs/codeconv/html/CodeConvTOC.doc.html coding standards] outlined by Sun are observed.<br />
Here are the coding standards that are particularly important to us:<br />
==== Capitalization ====<br />
Constants must be in all-capitals, with underscores between words:<br />
public static final int MAXIMUM_FILES = 100;<br />
<b>No</b> other identifiers may contain underscores but constants.<br />
Class, interface, enum and annotation names must be capitalized, with all subsequent words also capitalized:<br />
public class SampleClass extends AnotherSampleClass {<br />
Variable and member names must have their first letter lower-case, and subsequent words capitalized:<br />
private String fieldName;<br />
<br />
private abstract void processFile(File file);<br />
Some developers differentiate between method variables and class members by prepending <tt>m_</tt> or just <tt>_</tt> to member names.<br />
This is not a standard practice, so is not observed. Identifiers in property files are all lower-case with periods separating words:<br />
maximum.files=100<br />
Type wildcards in generics must be a single capital letter:<br />
public interface Generic&lt;T, S extends Serializable&gt; {<br />
==== Annotations ====<br />
Annotations can either appear on the same line as their associated declaration, or on the line before it:<br />
@Subscribe public void receive(Integer value) {<br />
<br />
@Script(dependencies = {STATE_UNINITIALIZED, STATE_COMPLETE}, result = STATE_INITIALIZED)<br />
public void initialize() {<br />
==== Variable Naming ====<br />
Variables should be given verbose names, even if they are only used in relatively small code blocks. Using the auto-complete functionality of modern IDEs makes compliance with this rule painless. Exceptions are simple index variables, such as those introduced in <code>for(;;)</code> statements:<br />
for (int i = 0; i < 100; i++) {<br />
==== Braces ====<br />
All <tt>if</tt>, <tt>while</tt> and similar block structures must be surrounded by braces, even if the body of the block consists of only one statement:<br />
if (index < 100) {<br />
System.out.println("index= " + index);<br />
}<br />
==== No Shortcuts ====<br />
Java provides some C-style shortcuts, such as the <code>++</code>, <code>+=</code> and <code>?:</code> operators. The <code>++</code>, <code>+=</code> operators can be used by themselves (for example, <code>++</code> is often used in a <code>for</code> statement) but they should not be included in other statements. The <code>?:</code> operator should only be used very sparingly, usually in statements that construct strings. Here is an example of a <b>bad</b> use of <code>++</code>:<br />
while (i < 100) {<br />
System.out.println("i= " + i++);<br />
}<br />
This is preferred:<br />
while (i < 100) {<br />
System.out.println("i= " + i);<br />
i++;<br />
}<br />
This is an acceptable use of <code>?:</code>:<br />
boolean available;<br />
...<br />
System.out.println("The file is " + (available ? "available" : "unavailable") + ".");<br />
However, it is a safe bet to never use <code>?:</code>.<br />
==== Tabs ====<br />
A tab-width of 4 should be used.<br />
<br />
=== Code Documentation ===<br />
Code must be documented using the [http://java.sun.com/j2se/javadoc/ Javadoc] standard.<br />
All classes, interfaces, enums and annotations must have an introductory Javadoc explaining its purpose.<br />
All public methods must also have explanatory Javadocs.<br />
Methods that perform non-trivial operations should have normal comments (not Javadoc) that explain the code.<br />
Such comments should precede the line (or lines) of code that they describe.<br />
For example:<br />
/**<br />
* Shuts down the componentRegistry (and terminates any pending aysnchronous dispatches).<br />
*/<br />
public void shutdown() {<br />
// Iterate through all active synch models<br />
Collection&lt;SynchModel&gt; models = synchModels.values();<br />
for (SynchModel synchModel : models) {<br />
// Shut down the synch model<br />
synchModel.shutdown();<br />
}<br />
}<br />
=== Packages ===<br />
Package names should follow the inverse-domain rule. If the domain of your organization is<br />
<code>subdomain.domain.tld</code>, then the package structure should be rooted at <code>tld.domain.subdomain</code>.<br />
Capital letters or underscore characters should never appear in package names.<br />
<br />
Otherwise, the organization of packages is left up to the developer.</div>Zjihttp://wiki.c2b2.columbia.edu/workbench/index.php?title=Style_Guide&diff=9702Style Guide2012-03-01T16:52:47Z<p>Zji: /* Project Structure */</p>
<hr />
<div>== geWorkbench Developer Style Guide ==<br />
This document provides a style guide for developers of geWorkbench. The old content that has not been updated since 2005 may include something useful, so I keep them for now at the end the page, titled "Old Content".<br />
<br />
There are various good style guides out there on the Internet, this document is meant to focus on the issues that are more relevant to the current code base and development activity of geWorkbench. While it is not practical to enforce the style over the legacy code, new development should follow the guide line described here. Any [mailto:zji@c2b2.columbia.edu comments] are very welcome.<br />
* Remove dead code. This includes: unused local variables, unused private members, unused public members, out-of-date comments, unused classes/files, unless you have specific reason to expect to use it soon or as part of unfinished development.<br />
* If a local variable is adequate to serve your purpose, do not make it a member variable.<br />
* If a private member serves your purpose, do not make it public or default or protected.<br />
* If the class is not intended to be extended, declare it as final - unless those require by geWorkbench framework not to be final.<br />
* If the method parameter is intended to be read only, declare it as final.<br />
* Name classes, variables, and methods what they really are or really do. If you cannot name your class as a noun, something is wrong with your design; if you cannot name your method as a verb, something is wrong with your design.<br />
* If one java file is over 1000 lines, the design deserves very careful scrutiny.<br />
* If class A refers to class B, and at the same time class B refers class A, the design needs scrutiny.<br />
* Refer to the object by a proper interface instead of implementation class when possible.<br />
* Immutable class is preferred. Particularly, do NOT implement setters for your class if you are not sure why it is necessary.<br />
<br />
== geWorkbench Code Organization Standard==<br />
<br />
=== Old Content ===<br />
=== Project Structure ===<br />
This section describes the directory structure of the project. The root directory structure contains eclipse project file, the <tt>java.policy</tt> file, the <tt>build.xml</tt> ant build file, and the following subdirectories besides other contents:<br />
* <tt>_all</tt> - out of date stuff - to be removed.<br />
* <tt>components</tt> - The top-level directory for geWorkbench components.<br />
* <tt>data</tt> - Sample data files for the project.<br />
* <tt>lib</tt> - Library files for core geWorkbench.<br />
* <tt>src</tt> - Source code for core geWorkbench.<br />
<br />
Each component is in a subdirectory of the <tt>components</tt> directory. It contains an eclipse project file and its directory structure is as follows:<br />
* <tt>lib</tt> - Library files depended on by this component.<br />
* <tt>src</tt> - Source code for the component.<br />
<br />
Note that the components can depend on the core classes (those defined in <tt>./src</tt>) and the core libraries (those defined in <tt>./lib</tt>). However, components cannot depend on each other, and the core classes cannot depend on components.<br />
<br />
=== Creating a New Component ===<br />
A new component should be added as a new subdirectory of <tt>components</tt>. The subdirectory should be given a simple, descriptive, lower-case name. It should contain <tt>src</tt> and <tt>lib</tt> directories. Most importantly, the component must not depend on the classes or libraries of any other component, nor should another component depend on it. Also, the core geWorkbench classes should not depend on its classes or libraries. The <tt>build.xml</tt> will enforce this, as will the IDEA project. However, the JBuilder project currently does not enforce this constraint, so be careful when using JBuilder.<br />
<br />
=== Coding Style ===<br />
The [http://java.sun.com/docs/codeconv/html/CodeConvTOC.doc.html coding standards] outlined by Sun are observed.<br />
Here are the coding standards that are particularly important to us:<br />
==== Capitalization ====<br />
Constants must be in all-capitals, with underscores between words:<br />
public static final int MAXIMUM_FILES = 100;<br />
<b>No</b> other identifiers may contain underscores but constants.<br />
Class, interface, enum and annotation names must be capitalized, with all subsequent words also capitalized:<br />
public class SampleClass extends AnotherSampleClass {<br />
Variable and member names must have their first letter lower-case, and subsequent words capitalized:<br />
private String fieldName;<br />
<br />
private abstract void processFile(File file);<br />
Some developers differentiate between method variables and class members by prepending <tt>m_</tt> or just <tt>_</tt> to member names.<br />
This is not a standard practice, so is not observed. Identifiers in property files are all lower-case with periods separating words:<br />
maximum.files=100<br />
Type wildcards in generics must be a single capital letter:<br />
public interface Generic&lt;T, S extends Serializable&gt; {<br />
==== Annotations ====<br />
Annotations can either appear on the same line as their associated declaration, or on the line before it:<br />
@Subscribe public void receive(Integer value) {<br />
<br />
@Script(dependencies = {STATE_UNINITIALIZED, STATE_COMPLETE}, result = STATE_INITIALIZED)<br />
public void initialize() {<br />
==== Variable Naming ====<br />
Variables should be given verbose names, even if they are only used in relatively small code blocks. Using the auto-complete functionality of modern IDEs makes compliance with this rule painless. Exceptions are simple index variables, such as those introduced in <code>for(;;)</code> statements:<br />
for (int i = 0; i < 100; i++) {<br />
==== Braces ====<br />
All <tt>if</tt>, <tt>while</tt> and similar block structures must be surrounded by braces, even if the body of the block consists of only one statement:<br />
if (index < 100) {<br />
System.out.println("index= " + index);<br />
}<br />
==== No Shortcuts ====<br />
Java provides some C-style shortcuts, such as the <code>++</code>, <code>+=</code> and <code>?:</code> operators. The <code>++</code>, <code>+=</code> operators can be used by themselves (for example, <code>++</code> is often used in a <code>for</code> statement) but they should not be included in other statements. The <code>?:</code> operator should only be used very sparingly, usually in statements that construct strings. Here is an example of a <b>bad</b> use of <code>++</code>:<br />
while (i < 100) {<br />
System.out.println("i= " + i++);<br />
}<br />
This is preferred:<br />
while (i < 100) {<br />
System.out.println("i= " + i);<br />
i++;<br />
}<br />
This is an acceptable use of <code>?:</code>:<br />
boolean available;<br />
...<br />
System.out.println("The file is " + (available ? "available" : "unavailable") + ".");<br />
However, it is a safe bet to never use <code>?:</code>.<br />
==== Tabs ====<br />
A tab-width of 4 should be used.<br />
<br />
=== Code Documentation ===<br />
Code must be documented using the [http://java.sun.com/j2se/javadoc/ Javadoc] standard.<br />
All classes, interfaces, enums and annotations must have an introductory Javadoc explaining its purpose.<br />
All public methods must also have explanatory Javadocs.<br />
Methods that perform non-trivial operations should have normal comments (not Javadoc) that explain the code.<br />
Such comments should precede the line (or lines) of code that they describe.<br />
For example:<br />
/**<br />
* Shuts down the componentRegistry (and terminates any pending aysnchronous dispatches).<br />
*/<br />
public void shutdown() {<br />
// Iterate through all active synch models<br />
Collection&lt;SynchModel&gt; models = synchModels.values();<br />
for (SynchModel synchModel : models) {<br />
// Shut down the synch model<br />
synchModel.shutdown();<br />
}<br />
}<br />
=== Packages ===<br />
Package names should follow the inverse-domain rule. If the domain of your organization is<br />
<code>subdomain.domain.tld</code>, then the package structure should be rooted at <code>tld.domain.subdomain</code>.<br />
Capital letters or underscore characters should never appear in package names.<br />
<br />
Otherwise, the organization of packages is left up to the developer.</div>Zjihttp://wiki.c2b2.columbia.edu/workbench/index.php?title=Style_Guide&diff=9701Style Guide2012-03-01T16:41:58Z<p>Zji: /* geWorkbench Developer Style Guide */</p>
<hr />
<div>== geWorkbench Developer Style Guide ==<br />
This document provides a style guide for developers of geWorkbench. The old content that has not been updated since 2005 may include something useful, so I keep them for now at the end the page, titled "Old Content".<br />
<br />
There are various good style guides out there on the Internet, this document is meant to focus on the issues that are more relevant to the current code base and development activity of geWorkbench. While it is not practical to enforce the style over the legacy code, new development should follow the guide line described here. Any [mailto:zji@c2b2.columbia.edu comments] are very welcome.<br />
* Remove dead code. This includes: unused local variables, unused private members, unused public members, out-of-date comments, unused classes/files, unless you have specific reason to expect to use it soon or as part of unfinished development.<br />
* If a local variable is adequate to serve your purpose, do not make it a member variable.<br />
* If a private member serves your purpose, do not make it public or default or protected.<br />
* If the class is not intended to be extended, declare it as final - unless those require by geWorkbench framework not to be final.<br />
* If the method parameter is intended to be read only, declare it as final.<br />
* Name classes, variables, and methods what they really are or really do. If you cannot name your class as a noun, something is wrong with your design; if you cannot name your method as a verb, something is wrong with your design.<br />
* If one java file is over 1000 lines, the design deserves very careful scrutiny.<br />
* If class A refers to class B, and at the same time class B refers class A, the design needs scrutiny.<br />
* Refer to the object by a proper interface instead of implementation class when possible.<br />
* Immutable class is preferred. Particularly, do NOT implement setters for your class if you are not sure why it is necessary.<br />
<br />
== geWorkbench Code Organization Standard==<br />
<br />
=== Old Content ===<br />
=== Project Structure ===<br />
This section describes the directory structure of the project. The root directory structure contains the JBuilder and IDEA project and library files. It also contains this file, the <tt>java.policy</tt> file, and the <tt>build.xml</tt> ant build file.<br />
* <tt>_all</tt> - A folder for a placeholder module required for the IDEA IDE.<br />
* <tt>annotation</tt> - Marker annotations for various chip types.<br />
* <tt>components</tt> - The top-level directory for geWorkbench components.<br />
* <tt>data</tt> - Sample data files for the project.<br />
* <tt>lib</tt> - Library files for core geWorkbench.<br />
* <tt>plugins</tt> - Plugins for the Cytoscape package.<br />
* <tt>src</tt> - Source code for core geWorkbench.<br />
<br />
Each component is in a subdirectory of the <tt>components</tt> directory. It contains an IDEA <tt>.iml</tt> module file and it's directory structure is as follows:<br />
* <tt>lib</tt> - Library files depended on by this component.<br />
* <tt>src</tt> - Source code for the component.<br />
<br />
Note that the components can depend on the core classes (those defined in <tt>./src</tt>) and the core libraries (those defined in <tt>./lib</tt>). However, components cannot depend on each other, and the core classes cannot depend on components.<br />
<br />
=== Creating a New Component ===<br />
A new component should be added as a new subdirectory of <tt>components</tt>. The subdirectory should be given a simple, descriptive, lower-case name. It should contain <tt>src</tt> and <tt>lib</tt> directories. Most importantly, the component must not depend on the classes or libraries of any other component, nor should another component depend on it. Also, the core geWorkbench classes should not depend on its classes or libraries. The <tt>build.xml</tt> will enforce this, as will the IDEA project. However, the JBuilder project currently does not enforce this constraint, so be careful when using JBuilder.<br />
<br />
=== Coding Style ===<br />
The [http://java.sun.com/docs/codeconv/html/CodeConvTOC.doc.html coding standards] outlined by Sun are observed.<br />
Here are the coding standards that are particularly important to us:<br />
==== Capitalization ====<br />
Constants must be in all-capitals, with underscores between words:<br />
public static final int MAXIMUM_FILES = 100;<br />
<b>No</b> other identifiers may contain underscores but constants.<br />
Class, interface, enum and annotation names must be capitalized, with all subsequent words also capitalized:<br />
public class SampleClass extends AnotherSampleClass {<br />
Variable and member names must have their first letter lower-case, and subsequent words capitalized:<br />
private String fieldName;<br />
<br />
private abstract void processFile(File file);<br />
Some developers differentiate between method variables and class members by prepending <tt>m_</tt> or just <tt>_</tt> to member names.<br />
This is not a standard practice, so is not observed. Identifiers in property files are all lower-case with periods separating words:<br />
maximum.files=100<br />
Type wildcards in generics must be a single capital letter:<br />
public interface Generic&lt;T, S extends Serializable&gt; {<br />
==== Annotations ====<br />
Annotations can either appear on the same line as their associated declaration, or on the line before it:<br />
@Subscribe public void receive(Integer value) {<br />
<br />
@Script(dependencies = {STATE_UNINITIALIZED, STATE_COMPLETE}, result = STATE_INITIALIZED)<br />
public void initialize() {<br />
==== Variable Naming ====<br />
Variables should be given verbose names, even if they are only used in relatively small code blocks. Using the auto-complete functionality of modern IDEs makes compliance with this rule painless. Exceptions are simple index variables, such as those introduced in <code>for(;;)</code> statements:<br />
for (int i = 0; i < 100; i++) {<br />
==== Braces ====<br />
All <tt>if</tt>, <tt>while</tt> and similar block structures must be surrounded by braces, even if the body of the block consists of only one statement:<br />
if (index < 100) {<br />
System.out.println("index= " + index);<br />
}<br />
==== No Shortcuts ====<br />
Java provides some C-style shortcuts, such as the <code>++</code>, <code>+=</code> and <code>?:</code> operators. The <code>++</code>, <code>+=</code> operators can be used by themselves (for example, <code>++</code> is often used in a <code>for</code> statement) but they should not be included in other statements. The <code>?:</code> operator should only be used very sparingly, usually in statements that construct strings. Here is an example of a <b>bad</b> use of <code>++</code>:<br />
while (i < 100) {<br />
System.out.println("i= " + i++);<br />
}<br />
This is preferred:<br />
while (i < 100) {<br />
System.out.println("i= " + i);<br />
i++;<br />
}<br />
This is an acceptable use of <code>?:</code>:<br />
boolean available;<br />
...<br />
System.out.println("The file is " + (available ? "available" : "unavailable") + ".");<br />
However, it is a safe bet to never use <code>?:</code>.<br />
==== Tabs ====<br />
A tab-width of 4 should be used.<br />
<br />
=== Code Documentation ===<br />
Code must be documented using the [http://java.sun.com/j2se/javadoc/ Javadoc] standard.<br />
All classes, interfaces, enums and annotations must have an introductory Javadoc explaining its purpose.<br />
All public methods must also have explanatory Javadocs.<br />
Methods that perform non-trivial operations should have normal comments (not Javadoc) that explain the code.<br />
Such comments should precede the line (or lines) of code that they describe.<br />
For example:<br />
/**<br />
* Shuts down the componentRegistry (and terminates any pending aysnchronous dispatches).<br />
*/<br />
public void shutdown() {<br />
// Iterate through all active synch models<br />
Collection&lt;SynchModel&gt; models = synchModels.values();<br />
for (SynchModel synchModel : models) {<br />
// Shut down the synch model<br />
synchModel.shutdown();<br />
}<br />
}<br />
=== Packages ===<br />
Package names should follow the inverse-domain rule. If the domain of your organization is<br />
<code>subdomain.domain.tld</code>, then the package structure should be rooted at <code>tld.domain.subdomain</code>.<br />
Capital letters or underscore characters should never appear in package names.<br />
<br />
Otherwise, the organization of packages is left up to the developer.</div>Zjihttp://wiki.c2b2.columbia.edu/workbench/index.php?title=Style_Guide&diff=9700Style Guide2012-03-01T16:41:45Z<p>Zji: /* geWorkbench Developer Style Guide */</p>
<hr />
<div>== geWorkbench Developer Style Guide ==<br />
This document provides a style guide for developers of geWorkbench. The old content that has not been updated since 2005 may include something useful, so I keep them for now at the end the page, titled "Old Content".<br />
<br />
There are various good style guides out there on the Internet, this document is meant to focus on the issues that are more relevant to the current code base and development activity of geWorkbench. While it is not practical to enforce the style over the legacy code, new development should follow the guide line described here. Any [mailto:zji@c2b2.columbia.edu comments] are very welcome.<br />
* Remove dead code. This includes: unused local variables, unused private members, unused public members, out-of-date comments, unused classes/files, unless you have specific reason to expect to use it soon or as part of unfinished development.<br />
* If a local variable is adequate to serve your purpose, do not make it a member variable.<br />
* If a private member serves your purpose, do not make it public or default or protected.<br />
* If the class is not intended to be extended, declare it as final - unless those require by geWorkbench framework not to be final.<br />
* If the method parameter is intended to be read only, declare it as final.<br />
* Name classes, variables, and methods what they really are or really do. If you cannot name your class as a noun, something is wrong with your design; if you cannot name your method as a verb, something is wrong with your design.<br />
* If one java file is over 1000 lines, the design deserves very careful scrutiny.<br />
* If class A refers to class B, and at the same time class B refers class A, the design needs scrutiny.<br />
* Refer to the object by a proper interface instead of implementation class when possible.<br />
* Immutable class is preferred. Particularly, do NOT implement setters for your class if you are not sure why it is necessisary.<br />
<br />
== geWorkbench Code Organization Standard==<br />
<br />
=== Old Content ===<br />
=== Project Structure ===<br />
This section describes the directory structure of the project. The root directory structure contains the JBuilder and IDEA project and library files. It also contains this file, the <tt>java.policy</tt> file, and the <tt>build.xml</tt> ant build file.<br />
* <tt>_all</tt> - A folder for a placeholder module required for the IDEA IDE.<br />
* <tt>annotation</tt> - Marker annotations for various chip types.<br />
* <tt>components</tt> - The top-level directory for geWorkbench components.<br />
* <tt>data</tt> - Sample data files for the project.<br />
* <tt>lib</tt> - Library files for core geWorkbench.<br />
* <tt>plugins</tt> - Plugins for the Cytoscape package.<br />
* <tt>src</tt> - Source code for core geWorkbench.<br />
<br />
Each component is in a subdirectory of the <tt>components</tt> directory. It contains an IDEA <tt>.iml</tt> module file and it's directory structure is as follows:<br />
* <tt>lib</tt> - Library files depended on by this component.<br />
* <tt>src</tt> - Source code for the component.<br />
<br />
Note that the components can depend on the core classes (those defined in <tt>./src</tt>) and the core libraries (those defined in <tt>./lib</tt>). However, components cannot depend on each other, and the core classes cannot depend on components.<br />
<br />
=== Creating a New Component ===<br />
A new component should be added as a new subdirectory of <tt>components</tt>. The subdirectory should be given a simple, descriptive, lower-case name. It should contain <tt>src</tt> and <tt>lib</tt> directories. Most importantly, the component must not depend on the classes or libraries of any other component, nor should another component depend on it. Also, the core geWorkbench classes should not depend on its classes or libraries. The <tt>build.xml</tt> will enforce this, as will the IDEA project. However, the JBuilder project currently does not enforce this constraint, so be careful when using JBuilder.<br />
<br />
=== Coding Style ===<br />
The [http://java.sun.com/docs/codeconv/html/CodeConvTOC.doc.html coding standards] outlined by Sun are observed.<br />
Here are the coding standards that are particularly important to us:<br />
==== Capitalization ====<br />
Constants must be in all-capitals, with underscores between words:<br />
public static final int MAXIMUM_FILES = 100;<br />
<b>No</b> other identifiers may contain underscores but constants.<br />
Class, interface, enum and annotation names must be capitalized, with all subsequent words also capitalized:<br />
public class SampleClass extends AnotherSampleClass {<br />
Variable and member names must have their first letter lower-case, and subsequent words capitalized:<br />
private String fieldName;<br />
<br />
private abstract void processFile(File file);<br />
Some developers differentiate between method variables and class members by prepending <tt>m_</tt> or just <tt>_</tt> to member names.<br />
This is not a standard practice, so is not observed. Identifiers in property files are all lower-case with periods separating words:<br />
maximum.files=100<br />
Type wildcards in generics must be a single capital letter:<br />
public interface Generic&lt;T, S extends Serializable&gt; {<br />
==== Annotations ====<br />
Annotations can either appear on the same line as their associated declaration, or on the line before it:<br />
@Subscribe public void receive(Integer value) {<br />
<br />
@Script(dependencies = {STATE_UNINITIALIZED, STATE_COMPLETE}, result = STATE_INITIALIZED)<br />
public void initialize() {<br />
==== Variable Naming ====<br />
Variables should be given verbose names, even if they are only used in relatively small code blocks. Using the auto-complete functionality of modern IDEs makes compliance with this rule painless. Exceptions are simple index variables, such as those introduced in <code>for(;;)</code> statements:<br />
for (int i = 0; i < 100; i++) {<br />
==== Braces ====<br />
All <tt>if</tt>, <tt>while</tt> and similar block structures must be surrounded by braces, even if the body of the block consists of only one statement:<br />
if (index < 100) {<br />
System.out.println("index= " + index);<br />
}<br />
==== No Shortcuts ====<br />
Java provides some C-style shortcuts, such as the <code>++</code>, <code>+=</code> and <code>?:</code> operators. The <code>++</code>, <code>+=</code> operators can be used by themselves (for example, <code>++</code> is often used in a <code>for</code> statement) but they should not be included in other statements. The <code>?:</code> operator should only be used very sparingly, usually in statements that construct strings. Here is an example of a <b>bad</b> use of <code>++</code>:<br />
while (i < 100) {<br />
System.out.println("i= " + i++);<br />
}<br />
This is preferred:<br />
while (i < 100) {<br />
System.out.println("i= " + i);<br />
i++;<br />
}<br />
This is an acceptable use of <code>?:</code>:<br />
boolean available;<br />
...<br />
System.out.println("The file is " + (available ? "available" : "unavailable") + ".");<br />
However, it is a safe bet to never use <code>?:</code>.<br />
==== Tabs ====<br />
A tab-width of 4 should be used.<br />
<br />
=== Code Documentation ===<br />
Code must be documented using the [http://java.sun.com/j2se/javadoc/ Javadoc] standard.<br />
All classes, interfaces, enums and annotations must have an introductory Javadoc explaining its purpose.<br />
All public methods must also have explanatory Javadocs.<br />
Methods that perform non-trivial operations should have normal comments (not Javadoc) that explain the code.<br />
Such comments should precede the line (or lines) of code that they describe.<br />
For example:<br />
/**<br />
* Shuts down the componentRegistry (and terminates any pending aysnchronous dispatches).<br />
*/<br />
public void shutdown() {<br />
// Iterate through all active synch models<br />
Collection&lt;SynchModel&gt; models = synchModels.values();<br />
for (SynchModel synchModel : models) {<br />
// Shut down the synch model<br />
synchModel.shutdown();<br />
}<br />
}<br />
=== Packages ===<br />
Package names should follow the inverse-domain rule. If the domain of your organization is<br />
<code>subdomain.domain.tld</code>, then the package structure should be rooted at <code>tld.domain.subdomain</code>.<br />
Capital letters or underscore characters should never appear in package names.<br />
<br />
Otherwise, the organization of packages is left up to the developer.</div>Zjihttp://wiki.c2b2.columbia.edu/workbench/index.php?title=Developers&diff=9464Developers2012-02-23T17:09:46Z<p>Zji: </p>
<hr />
<div>{{DevelopersTopNav}}<br />
<br />
geWorkbench is an open source Java-based platform and contributions by members of the community are welcome and encouraged. The latest code under development can be found at NCI's subversion server, https://ncisvn.nci.nih.gov/svn/geworkbench/trunk/geworkbench/. Anonymous read access is supported for all the code.<br />
<br />
<br />
Development in geWorkbench takes place along 2 lines:<br />
* <u>'''geWorkbench core'''</u>: this portion of the code includes mainly 7 groups of packages:<br />
# ''engine'', which implements services related to the geWorkbench component architecture framework (e.g., plugin instantiation and visual layout, message delivery, component registry management, etc)<br />
# ''bison'' ('''B'''iomedical '''I'''nformatics '''S'''tructured '''ON'''tology) which contains the definition of the bioinformatics data types which form the basis of communication between the geWorkbench plugins.<br />
# ''builtin'', supporting the internal execution and coordination of the core process, especially the project panel<br />
# ''parsers'', parsing supports for input data format<br />
# ''events'', event classes used by communication between all components and the core<br />
# ''util'', all the utility libraries<br />
# ''analysis'', a small number of classes providing abstract for analyses and savable parameter settings. This group used to be called "others" to include miscellaneous; ''analysis'' is the only one left now. This probably will be re-organized in the future.<br />
* <u>'''geWorkbench plugins'''</u>: this portion of the source tree contains the code for the various application plugin components (sample code for creating a simple plugin can be found [[A_Simple_Plugin |here]])<br />
<br />
There are no restrictions on who can develop a new component for geWorkbench. You can work against the development version or a release version of the geWorkbench core. To contribute your component to geWorkbench code, you need write access to the subversion server. Please contact us for the procedure.<br />
Contributions to the geWorkbench core packages are more controlled in order to avoid changes that may adversely affect large numbers of plugins.</div>Zjihttp://wiki.c2b2.columbia.edu/workbench/index.php?title=Template:DevelopersTopNav&diff=9459Template:DevelopersTopNav2012-02-23T16:40:16Z<p>Zji: </p>
<hr />
<div>{| border="1" cellpadding="5"<br />
|<br />
[[Developers | Developers Home]] |<br />
[[A Simple Plugin]] | <br />
[[.GEAR_files | geWorkbench Archive Files]] | <br />
[[Collaborative Development]] |<br />
[[Design Documentation]] | <br />
[{{SERVER}}/workbench/api Javadocs] | <br />
[http://gforge.nci.nih.gov/projects/geworkbench gForge Page] |<br />
[[Report Defects]]<br />
|}<br />
<br/></div>Zjihttp://wiki.c2b2.columbia.edu/workbench/index.php?title=Software_Development_Kit&diff=9458Software Development Kit2012-02-23T16:38:32Z<p>Zji: </p>
<hr />
<div>{{DevelopersTopNav}}<br />
<br />
* This page is out of date. There is not much value for the developers to have a separate SDK besides the downloadable geWorkbench package and the code base from subversion, which includes an example plug-in. I will remove the link of this page from the Developers section (to avoid confusion) instead of maintainining this page. Feb 23, 2012. - Zhou Ji<br />
<br />
The Development Kit is a self-contained package that facilitates the process of developing plugins for geWorkbench. <br />
<br />
== Using the Development Kit ==<br />
<br />
The Development Kit is available as a .zip file (see [[Download]] page). Unzip this archive, then follow the instructions below to create a geWorkbench plugin. Prerequisites to using the SDK are installing [http://ant.apache.org/manual/index.html ANT] and a [[Download#Software_Requirements|supported version]] of Java.<br />
<br />
The high-level steps for creating, testing and releasing a plugin are as follows:<br />
<br />
# From the command line, ''cd'' into the directory created after unpacking the archive.<br />
# Edit the provided Apache Ant build script to specify the name of your plugin.<br />
# Add the .java source files for your plugin to the <tt>src</tt> directory.<br />
# Add any .jar libraries that your plugin requires to the <tt>lib</tt> directory.<br />
# Run <tt>ant</tt> to build your plugin.<br />
# Edit the geWorkbench configuration file to add a directive for your new plugin.<br />
# Run geWorkbench with <tt>ant run</tt> to test your plugin.<br />
# Once satisfied with your plugin, use the provided utility to package your plugin in to a single file for distribution.<br />
<br />
The next section will illustrate the above steps with an example.<br />
<br />
== An Example Plugin (geworkbench 1.7 or later) ==<br />
<br />
We will create an example plugin that is simply called <tt>test</tt>. This will be a very simple visualization plugin that just displays a blank blue region.<br />
<br />
=== Setting the Plugin Name ===<br />
<br />
In the provided <tt>build.xml</tt>, change this line:<br />
<br />
<property name="component" value="noname"/><br />
<br />
to:<br />
<br />
<property name="component" value="test"/><br />
<br />
This specifies the name of our component, which is used for all build products.<br />
<br />
=== Adding Source ===<br />
<br />
Next, create and add a single .java source file to the org.organization.test package. To do this, first, create the file <tt>TestComponent.java</tt> (in your favorite editor) and copy and paste the code below in this file. Then, create the directories <tt>src/org/organization/test</tt> in /src and place <tt>TestComponent.java</tt> file in this directory.<br />
<br />
package org.organization.test;<br />
<br />
import org.geworkbench.engine.config.VisualPlugin;<br />
<br />
import javax.swing.*;<br />
import java.awt.*;<br />
<br />
/**<br />
* A simple demonstration component.<br />
*/<br />
public class TestComponent implements VisualPlugin {<br />
<br />
private JPanel panel;<br />
<br />
public TestComponent() {<br />
panel = new JPanel();<br />
panel.setBackground(Color.blue);<br />
}<br />
<br />
public Component getComponent() {<br />
return panel;<br />
}<br />
}<br />
<br />
If the component requires any .jar files, add them to the <tt>lib</tt> directory.<br />
<br />
=== Configure Plugin ===<br />
<br />
Create a .cwb.xml file for your plugin and place it under the same directory as the source file. In this case, create ''test.cwb.xml'' and place it under ''GEWORKBENCHSDK_HOME/src/org/organization/test''.<br />
<br />
<component-descriptor xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="ConfigurationFile Schema.xsd"><br />
<component name="Test SDK Panel" <br />
class="org.organization.test.TestComponent" <br />
version="1.0"<br />
author="C2B2"<br />
authorURL=""<br />
toolURL=""<br />
description="test SDK"<br />
visualizer="true"><br />
<license><br />
<![CDATA[<br />
<html><head><meta http-equiv=Content-Type content="text/html; charset=windows-1252"></head><br />
<body>----</body><br />
</html><br />
]]></license><br />
</component><br />
<plugin id="TestSDKPanel" name="Test SDK" class="org.organization.test.TestComponent" source="test"><br />
<gui-area name="VisualArea"/><br />
</plugin><br />
</component-descriptor><br />
<br />
=== Running the Plugin in geWorkbench ===<br />
<br />
To run the plugin and see it appear in geWorkbench (a blue visual), do the following:<br />
<br />
ant run<br />
<br />
When geWorkbench appears, right click on the ''Workspace'' and select ''New Project''. You should see the blue visual plugin.<br />
<br />
=== Releasing the Plugin ===<br />
<br />
To create a plugin release, type:<br />
<br />
ant gear<br />
<br />
This creates the file <tt>test.gear</tt>. This gear file is a bundled plugin that can deployed to a geWorkbench installation by placing the file in the <tt>components</tt> directory, then unzipping it.<br />
<br />
== An Example Plugin (Pre geworkbench 1.7) ==<br />
<br />
We will create an example plugin that is simply called <tt>test</tt>. This will be a very simple visualization plugin that just displays a blank blue region.<br />
<br />
=== Setting the Plugin Name ===<br />
<br />
In the provided <tt>build.xml</tt>, change this line:<br />
<br />
<property name="component" value="noname"/><br />
<br />
to:<br />
<br />
<property name="component" value="test"/><br />
<br />
This specifies the name of our component, which is used for all build products.<br />
<br />
=== Adding Source ===<br />
<br />
Next, create and add a single .java source file to the org.organization.test package. To do this, first, create the file <tt>TestComponent.java</tt> (in your favorite editor) and copy and paste the code below in this file. Then, create the directories <tt>src/org/organization/test</tt> in /src and place <tt>TestComponent.java</tt> file in this directory.<br />
<br />
package org.organization.test;<br />
<br />
import org.geworkbench.engine.config.VisualPlugin;<br />
<br />
import javax.swing.*;<br />
import java.awt.*;<br />
<br />
/**<br />
* A simple demonstration component.<br />
*/<br />
public class TestComponent implements VisualPlugin {<br />
<br />
private JPanel panel;<br />
<br />
public TestComponent() {<br />
panel = new JPanel();<br />
panel.setBackground(Color.blue);<br />
}<br />
<br />
public Component getComponent() {<br />
return panel;<br />
}<br />
}<br />
<br />
If the component requires any .jar files, add them to the <tt>lib</tt> directory.<br />
<br />
=== Configure Plugin ===<br />
<br />
The configuration file for the Development Kit is called <tt>minimal.xml</tt> and it is in the <tt>conf</tt> directory. <br />
<br />
Add the following to the bottom of <tt>minimal.xml</tt> (before ''</geaw-config>''):<br />
<br />
<plugin id="testPanel" name="Test Panel" class="org.organization.test.TestComponent" source="test"><br />
<gui-area name="VisualArea"/><br />
</plugin><br />
<br />
=== Running the Plugin in geWorkbench ===<br />
<br />
To run the plugn and see it appear in geWorkbench (a blue visual), do the following:<br />
<br />
ant run<br />
<br />
When geWorkbench appears, right click on the ''Workspace'' and select ''New Project''. You should see the blue visual plugin.<br />
<br />
=== Releasing the Plugin ===<br />
<br />
To create a plugin release, type:<br />
<br />
ant gear<br />
<br />
This creates the file <tt>test.gear</tt>. A .gear file is the geWorkbench analogue of a .war file for a web application. Is a bundled plugin that can deployed to a geWorkbench install by placing the file in the <tt>components</tt> directory. A configuration directive (such as the one above) would also need to be added to the configuration file to activate the plugin.</div>Zjihttp://wiki.c2b2.columbia.edu/workbench/index.php?title=Style_Guide&diff=9231Style Guide2011-10-28T13:57:21Z<p>Zji: /* geWorkbench Developer Style Guide */</p>
<hr />
<div>== geWorkbench Developer Style Guide ==<br />
This document provides a style guide for developers of geWorkbench. The old content that has not been updated since 2005 may include something useful, so I keep them for now at the end the page, titled "Old Content".<br />
<br />
There are various good style guides out there on the Internet, this document is meant to focus on the issues that are more relevant to the current code base and development activity of geWorkbench. While it is not practical to enforce the style over the legacy code, new development should follow the guide line described here. Any [mailto:zji@c2b2.columbia.edu comments] are very welcome.<br />
* Remove dead code. This includes: unused local variables, unused private members, unused public members, out-of-date comments, unused classes/files, unless you have specific reason to expect to use it soon or as part of unfinished development.<br />
* If a local variable is adequate to serve your purpose, do not make it a member variable.<br />
* If a private member serves your purpose, do not make it public or default or protected.<br />
* If the class is not intended to be extended, declare it as final - unless those require by geWorkbench framework not to be final.<br />
* If the method parameter is intended to be read only, declare it as final.<br />
* Name classes, variables, and methods what they really are or really do. If you cannot name your class as a noun, something is wrong with your design; if you cannot name your method as a verb, something is wrong with your design.<br />
* If one java file is over 1000 lines, the design deserves very careful scrutiny.<br />
* If class A refers to class B, and at the same time class B refers class A, the design needs scrutiny.<br />
* Refer to the object by a proper interface instead of implementation class when possible.<br />
<br />
== geWorkbench Code Organization Standard==<br />
<br />
=== Old Content ===<br />
=== Project Structure ===<br />
This section describes the directory structure of the project. The root directory structure contains the JBuilder and IDEA project and library files. It also contains this file, the <tt>java.policy</tt> file, and the <tt>build.xml</tt> ant build file.<br />
* <tt>_all</tt> - A folder for a placeholder module required for the IDEA IDE.<br />
* <tt>annotation</tt> - Marker annotations for various chip types.<br />
* <tt>components</tt> - The top-level directory for geWorkbench components.<br />
* <tt>data</tt> - Sample data files for the project.<br />
* <tt>lib</tt> - Library files for core geWorkbench.<br />
* <tt>plugins</tt> - Plugins for the Cytoscape package.<br />
* <tt>src</tt> - Source code for core geWorkbench.<br />
<br />
Each component is in a subdirectory of the <tt>components</tt> directory. It contains an IDEA <tt>.iml</tt> module file and it's directory structure is as follows:<br />
* <tt>lib</tt> - Library files depended on by this component.<br />
* <tt>src</tt> - Source code for the component.<br />
<br />
Note that the components can depend on the core classes (those defined in <tt>./src</tt>) and the core libraries (those defined in <tt>./lib</tt>). However, components cannot depend on each other, and the core classes cannot depend on components.<br />
<br />
=== Creating a New Component ===<br />
A new component should be added as a new subdirectory of <tt>components</tt>. The subdirectory should be given a simple, descriptive, lower-case name. It should contain <tt>src</tt> and <tt>lib</tt> directories. Most importantly, the component must not depend on the classes or libraries of any other component, nor should another component depend on it. Also, the core geWorkbench classes should not depend on its classes or libraries. The <tt>build.xml</tt> will enforce this, as will the IDEA project. However, the JBuilder project currently does not enforce this constraint, so be careful when using JBuilder.<br />
<br />
=== Coding Style ===<br />
The [http://java.sun.com/docs/codeconv/html/CodeConvTOC.doc.html coding standards] outlined by Sun are observed.<br />
Here are the coding standards that are particularly important to us:<br />
==== Capitalization ====<br />
Constants must be in all-capitals, with underscores between words:<br />
public static final int MAXIMUM_FILES = 100;<br />
<b>No</b> other identifiers may contain underscores but constants.<br />
Class, interface, enum and annotation names must be capitalized, with all subsequent words also capitalized:<br />
public class SampleClass extends AnotherSampleClass {<br />
Variable and member names must have their first letter lower-case, and subsequent words capitalized:<br />
private String fieldName;<br />
<br />
private abstract void processFile(File file);<br />
Some developers differentiate between method variables and class members by prepending <tt>m_</tt> or just <tt>_</tt> to member names.<br />
This is not a standard practice, so is not observed. Identifiers in property files are all lower-case with periods separating words:<br />
maximum.files=100<br />
Type wildcards in generics must be a single capital letter:<br />
public interface Generic&lt;T, S extends Serializable&gt; {<br />
==== Annotations ====<br />
Annotations can either appear on the same line as their associated declaration, or on the line before it:<br />
@Subscribe public void receive(Integer value) {<br />
<br />
@Script(dependencies = {STATE_UNINITIALIZED, STATE_COMPLETE}, result = STATE_INITIALIZED)<br />
public void initialize() {<br />
==== Variable Naming ====<br />
Variables should be given verbose names, even if they are only used in relatively small code blocks. Using the auto-complete functionality of modern IDEs makes compliance with this rule painless. Exceptions are simple index variables, such as those introduced in <code>for(;;)</code> statements:<br />
for (int i = 0; i < 100; i++) {<br />
==== Braces ====<br />
All <tt>if</tt>, <tt>while</tt> and similar block structures must be surrounded by braces, even if the body of the block consists of only one statement:<br />
if (index < 100) {<br />
System.out.println("index= " + index);<br />
}<br />
==== No Shortcuts ====<br />
Java provides some C-style shortcuts, such as the <code>++</code>, <code>+=</code> and <code>?:</code> operators. The <code>++</code>, <code>+=</code> operators can be used by themselves (for example, <code>++</code> is often used in a <code>for</code> statement) but they should not be included in other statements. The <code>?:</code> operator should only be used very sparingly, usually in statements that construct strings. Here is an example of a <b>bad</b> use of <code>++</code>:<br />
while (i < 100) {<br />
System.out.println("i= " + i++);<br />
}<br />
This is preferred:<br />
while (i < 100) {<br />
System.out.println("i= " + i);<br />
i++;<br />
}<br />
This is an acceptable use of <code>?:</code>:<br />
boolean available;<br />
...<br />
System.out.println("The file is " + (available ? "available" : "unavailable") + ".");<br />
However, it is a safe bet to never use <code>?:</code>.<br />
==== Tabs ====<br />
A tab-width of 4 should be used.<br />
<br />
=== Code Documentation ===<br />
Code must be documented using the [http://java.sun.com/j2se/javadoc/ Javadoc] standard.<br />
All classes, interfaces, enums and annotations must have an introductory Javadoc explaining its purpose.<br />
All public methods must also have explanatory Javadocs.<br />
Methods that perform non-trivial operations should have normal comments (not Javadoc) that explain the code.<br />
Such comments should precede the line (or lines) of code that they describe.<br />
For example:<br />
/**<br />
* Shuts down the componentRegistry (and terminates any pending aysnchronous dispatches).<br />
*/<br />
public void shutdown() {<br />
// Iterate through all active synch models<br />
Collection&lt;SynchModel&gt; models = synchModels.values();<br />
for (SynchModel synchModel : models) {<br />
// Shut down the synch model<br />
synchModel.shutdown();<br />
}<br />
}<br />
=== Packages ===<br />
Package names should follow the inverse-domain rule. If the domain of your organization is<br />
<code>subdomain.domain.tld</code>, then the package structure should be rooted at <code>tld.domain.subdomain</code>.<br />
Capital letters or underscore characters should never appear in package names.<br />
<br />
Otherwise, the organization of packages is left up to the developer.</div>Zjihttp://wiki.c2b2.columbia.edu/workbench/index.php?title=Style_Guide&diff=9230Style Guide2011-10-27T22:14:50Z<p>Zji: /* geWorkbench Developer Style Guide */</p>
<hr />
<div>== geWorkbench Developer Style Guide ==<br />
This document provides a style guide for developers of geWorkbench. The old content that has not been updated since 2005 may include something useful, so I keep them for now at the end the page, titled "Old Content".<br />
<br />
There are various good style guides out there on the Internet, this document is meant to focus on the issues that are more relevant to the current code base and development activity of geWorkbench. While it is not practical to enforce the style over the legacy code, new development should follow the guide line described here. Any [mailto:zji@c2b2.columbia.edu comments] are very welcome.<br />
* Remove dead code. This includes: unused local variables, unused private members, unused public members, out-of-date comments, unused classes/files, unless you have specific reason to expect to use it soon or as part of unfinished development.<br />
* If a local variable is adequate to serve your purpose, do not make it a member variable.<br />
* If a private member serves your purpose, do not make it public or default or protected.<br />
* If the class is intended to be extended, declare it as final - unless those require by geWorkbench framework not to be final.<br />
* If the method parameter is intended to be read only, declare it as final.<br />
* Name classes, variables, and methods what they really are or really do. If you cannot name your class as a noun, something is wrong with your design; if you cannot name your method as a verb, something is wrong with your design.<br />
* If one java file is over 1000 lines, the design deserves very careful scrutiny.<br />
* If class A refers to class B, and at the same time class B refers class A, the design needs scrutiny.<br />
* Refer to the object by a proper interface instead of implementation class when possible.<br />
<br />
== geWorkbench Code Organization Standard==<br />
<br />
=== Old Content ===<br />
=== Project Structure ===<br />
This section describes the directory structure of the project. The root directory structure contains the JBuilder and IDEA project and library files. It also contains this file, the <tt>java.policy</tt> file, and the <tt>build.xml</tt> ant build file.<br />
* <tt>_all</tt> - A folder for a placeholder module required for the IDEA IDE.<br />
* <tt>annotation</tt> - Marker annotations for various chip types.<br />
* <tt>components</tt> - The top-level directory for geWorkbench components.<br />
* <tt>data</tt> - Sample data files for the project.<br />
* <tt>lib</tt> - Library files for core geWorkbench.<br />
* <tt>plugins</tt> - Plugins for the Cytoscape package.<br />
* <tt>src</tt> - Source code for core geWorkbench.<br />
<br />
Each component is in a subdirectory of the <tt>components</tt> directory. It contains an IDEA <tt>.iml</tt> module file and it's directory structure is as follows:<br />
* <tt>lib</tt> - Library files depended on by this component.<br />
* <tt>src</tt> - Source code for the component.<br />
<br />
Note that the components can depend on the core classes (those defined in <tt>./src</tt>) and the core libraries (those defined in <tt>./lib</tt>). However, components cannot depend on each other, and the core classes cannot depend on components.<br />
<br />
=== Creating a New Component ===<br />
A new component should be added as a new subdirectory of <tt>components</tt>. The subdirectory should be given a simple, descriptive, lower-case name. It should contain <tt>src</tt> and <tt>lib</tt> directories. Most importantly, the component must not depend on the classes or libraries of any other component, nor should another component depend on it. Also, the core geWorkbench classes should not depend on its classes or libraries. The <tt>build.xml</tt> will enforce this, as will the IDEA project. However, the JBuilder project currently does not enforce this constraint, so be careful when using JBuilder.<br />
<br />
=== Coding Style ===<br />
The [http://java.sun.com/docs/codeconv/html/CodeConvTOC.doc.html coding standards] outlined by Sun are observed.<br />
Here are the coding standards that are particularly important to us:<br />
==== Capitalization ====<br />
Constants must be in all-capitals, with underscores between words:<br />
public static final int MAXIMUM_FILES = 100;<br />
<b>No</b> other identifiers may contain underscores but constants.<br />
Class, interface, enum and annotation names must be capitalized, with all subsequent words also capitalized:<br />
public class SampleClass extends AnotherSampleClass {<br />
Variable and member names must have their first letter lower-case, and subsequent words capitalized:<br />
private String fieldName;<br />
<br />
private abstract void processFile(File file);<br />
Some developers differentiate between method variables and class members by prepending <tt>m_</tt> or just <tt>_</tt> to member names.<br />
This is not a standard practice, so is not observed. Identifiers in property files are all lower-case with periods separating words:<br />
maximum.files=100<br />
Type wildcards in generics must be a single capital letter:<br />
public interface Generic&lt;T, S extends Serializable&gt; {<br />
==== Annotations ====<br />
Annotations can either appear on the same line as their associated declaration, or on the line before it:<br />
@Subscribe public void receive(Integer value) {<br />
<br />
@Script(dependencies = {STATE_UNINITIALIZED, STATE_COMPLETE}, result = STATE_INITIALIZED)<br />
public void initialize() {<br />
==== Variable Naming ====<br />
Variables should be given verbose names, even if they are only used in relatively small code blocks. Using the auto-complete functionality of modern IDEs makes compliance with this rule painless. Exceptions are simple index variables, such as those introduced in <code>for(;;)</code> statements:<br />
for (int i = 0; i < 100; i++) {<br />
==== Braces ====<br />
All <tt>if</tt>, <tt>while</tt> and similar block structures must be surrounded by braces, even if the body of the block consists of only one statement:<br />
if (index < 100) {<br />
System.out.println("index= " + index);<br />
}<br />
==== No Shortcuts ====<br />
Java provides some C-style shortcuts, such as the <code>++</code>, <code>+=</code> and <code>?:</code> operators. The <code>++</code>, <code>+=</code> operators can be used by themselves (for example, <code>++</code> is often used in a <code>for</code> statement) but they should not be included in other statements. The <code>?:</code> operator should only be used very sparingly, usually in statements that construct strings. Here is an example of a <b>bad</b> use of <code>++</code>:<br />
while (i < 100) {<br />
System.out.println("i= " + i++);<br />
}<br />
This is preferred:<br />
while (i < 100) {<br />
System.out.println("i= " + i);<br />
i++;<br />
}<br />
This is an acceptable use of <code>?:</code>:<br />
boolean available;<br />
...<br />
System.out.println("The file is " + (available ? "available" : "unavailable") + ".");<br />
However, it is a safe bet to never use <code>?:</code>.<br />
==== Tabs ====<br />
A tab-width of 4 should be used.<br />
<br />
=== Code Documentation ===<br />
Code must be documented using the [http://java.sun.com/j2se/javadoc/ Javadoc] standard.<br />
All classes, interfaces, enums and annotations must have an introductory Javadoc explaining its purpose.<br />
All public methods must also have explanatory Javadocs.<br />
Methods that perform non-trivial operations should have normal comments (not Javadoc) that explain the code.<br />
Such comments should precede the line (or lines) of code that they describe.<br />
For example:<br />
/**<br />
* Shuts down the componentRegistry (and terminates any pending aysnchronous dispatches).<br />
*/<br />
public void shutdown() {<br />
// Iterate through all active synch models<br />
Collection&lt;SynchModel&gt; models = synchModels.values();<br />
for (SynchModel synchModel : models) {<br />
// Shut down the synch model<br />
synchModel.shutdown();<br />
}<br />
}<br />
=== Packages ===<br />
Package names should follow the inverse-domain rule. If the domain of your organization is<br />
<code>subdomain.domain.tld</code>, then the package structure should be rooted at <code>tld.domain.subdomain</code>.<br />
Capital letters or underscore characters should never appear in package names.<br />
<br />
Otherwise, the organization of packages is left up to the developer.</div>Zjihttp://wiki.c2b2.columbia.edu/workbench/index.php?title=Style_Guide&diff=9229Style Guide2011-10-27T22:08:41Z<p>Zji: /* geWorkbench Developer Guide */</p>
<hr />
<div>== geWorkbench Developer Style Guide ==<br />
This document provides a style guide for developers of geWorkbench. The old content that has not been updated since 2005 may include something useful, so I keep them for now at the end the page, titled "Old Content".<br />
<br />
There are various good style guides out there on the Internet, this document is meant to focus on the issues that are more relevant to the current code base and development activity of geWorkbench. While it is not practical to enforce the style over the legacy code, new development should follow the guide line described here.<br />
* Remove dead code. This includes: unused local variables, unused private members, unused public members, out-of-date comments, unused classes/files, unless you have specific reason to expect to use it soon or as part of unfinished development.<br />
* If a local variable is adequate to serve your purpose, do not make it a member variable.<br />
* If a private member serves your purpose, do not make it public or default or protected.<br />
* If the class is intended to be extended, declare it as final - unless those require by geWorkbench framework not to be final.<br />
* If the method parameter is intended to be read only, declare it as final.<br />
* Name classes, variables, and methods what they really are or really do. If you cannot name your class as a noun, something is wrong with your design; if you cannot name your method as a verb, something is wrong with your design.<br />
* If one java file is over 1000 lines, the design deserves very careful scrutiny.<br />
* If class A refers to class B, and at the same time class B refers class A, the design needs scrutiny.<br />
* Refer to the object by a proper interface instead of implementation class when possible.<br />
<br />
== geWorkbench Code Organization Standard==<br />
<br />
=== Old Content ===<br />
=== Project Structure ===<br />
This section describes the directory structure of the project. The root directory structure contains the JBuilder and IDEA project and library files. It also contains this file, the <tt>java.policy</tt> file, and the <tt>build.xml</tt> ant build file.<br />
* <tt>_all</tt> - A folder for a placeholder module required for the IDEA IDE.<br />
* <tt>annotation</tt> - Marker annotations for various chip types.<br />
* <tt>components</tt> - The top-level directory for geWorkbench components.<br />
* <tt>data</tt> - Sample data files for the project.<br />
* <tt>lib</tt> - Library files for core geWorkbench.<br />
* <tt>plugins</tt> - Plugins for the Cytoscape package.<br />
* <tt>src</tt> - Source code for core geWorkbench.<br />
<br />
Each component is in a subdirectory of the <tt>components</tt> directory. It contains an IDEA <tt>.iml</tt> module file and it's directory structure is as follows:<br />
* <tt>lib</tt> - Library files depended on by this component.<br />
* <tt>src</tt> - Source code for the component.<br />
<br />
Note that the components can depend on the core classes (those defined in <tt>./src</tt>) and the core libraries (those defined in <tt>./lib</tt>). However, components cannot depend on each other, and the core classes cannot depend on components.<br />
<br />
=== Creating a New Component ===<br />
A new component should be added as a new subdirectory of <tt>components</tt>. The subdirectory should be given a simple, descriptive, lower-case name. It should contain <tt>src</tt> and <tt>lib</tt> directories. Most importantly, the component must not depend on the classes or libraries of any other component, nor should another component depend on it. Also, the core geWorkbench classes should not depend on its classes or libraries. The <tt>build.xml</tt> will enforce this, as will the IDEA project. However, the JBuilder project currently does not enforce this constraint, so be careful when using JBuilder.<br />
<br />
=== Coding Style ===<br />
The [http://java.sun.com/docs/codeconv/html/CodeConvTOC.doc.html coding standards] outlined by Sun are observed.<br />
Here are the coding standards that are particularly important to us:<br />
==== Capitalization ====<br />
Constants must be in all-capitals, with underscores between words:<br />
public static final int MAXIMUM_FILES = 100;<br />
<b>No</b> other identifiers may contain underscores but constants.<br />
Class, interface, enum and annotation names must be capitalized, with all subsequent words also capitalized:<br />
public class SampleClass extends AnotherSampleClass {<br />
Variable and member names must have their first letter lower-case, and subsequent words capitalized:<br />
private String fieldName;<br />
<br />
private abstract void processFile(File file);<br />
Some developers differentiate between method variables and class members by prepending <tt>m_</tt> or just <tt>_</tt> to member names.<br />
This is not a standard practice, so is not observed. Identifiers in property files are all lower-case with periods separating words:<br />
maximum.files=100<br />
Type wildcards in generics must be a single capital letter:<br />
public interface Generic&lt;T, S extends Serializable&gt; {<br />
==== Annotations ====<br />
Annotations can either appear on the same line as their associated declaration, or on the line before it:<br />
@Subscribe public void receive(Integer value) {<br />
<br />
@Script(dependencies = {STATE_UNINITIALIZED, STATE_COMPLETE}, result = STATE_INITIALIZED)<br />
public void initialize() {<br />
==== Variable Naming ====<br />
Variables should be given verbose names, even if they are only used in relatively small code blocks. Using the auto-complete functionality of modern IDEs makes compliance with this rule painless. Exceptions are simple index variables, such as those introduced in <code>for(;;)</code> statements:<br />
for (int i = 0; i < 100; i++) {<br />
==== Braces ====<br />
All <tt>if</tt>, <tt>while</tt> and similar block structures must be surrounded by braces, even if the body of the block consists of only one statement:<br />
if (index < 100) {<br />
System.out.println("index= " + index);<br />
}<br />
==== No Shortcuts ====<br />
Java provides some C-style shortcuts, such as the <code>++</code>, <code>+=</code> and <code>?:</code> operators. The <code>++</code>, <code>+=</code> operators can be used by themselves (for example, <code>++</code> is often used in a <code>for</code> statement) but they should not be included in other statements. The <code>?:</code> operator should only be used very sparingly, usually in statements that construct strings. Here is an example of a <b>bad</b> use of <code>++</code>:<br />
while (i < 100) {<br />
System.out.println("i= " + i++);<br />
}<br />
This is preferred:<br />
while (i < 100) {<br />
System.out.println("i= " + i);<br />
i++;<br />
}<br />
This is an acceptable use of <code>?:</code>:<br />
boolean available;<br />
...<br />
System.out.println("The file is " + (available ? "available" : "unavailable") + ".");<br />
However, it is a safe bet to never use <code>?:</code>.<br />
==== Tabs ====<br />
A tab-width of 4 should be used.<br />
<br />
=== Code Documentation ===<br />
Code must be documented using the [http://java.sun.com/j2se/javadoc/ Javadoc] standard.<br />
All classes, interfaces, enums and annotations must have an introductory Javadoc explaining its purpose.<br />
All public methods must also have explanatory Javadocs.<br />
Methods that perform non-trivial operations should have normal comments (not Javadoc) that explain the code.<br />
Such comments should precede the line (or lines) of code that they describe.<br />
For example:<br />
/**<br />
* Shuts down the componentRegistry (and terminates any pending aysnchronous dispatches).<br />
*/<br />
public void shutdown() {<br />
// Iterate through all active synch models<br />
Collection&lt;SynchModel&gt; models = synchModels.values();<br />
for (SynchModel synchModel : models) {<br />
// Shut down the synch model<br />
synchModel.shutdown();<br />
}<br />
}<br />
=== Packages ===<br />
Package names should follow the inverse-domain rule. If the domain of your organization is<br />
<code>subdomain.domain.tld</code>, then the package structure should be rooted at <code>tld.domain.subdomain</code>.<br />
Capital letters or underscore characters should never appear in package names.<br />
<br />
Otherwise, the organization of packages is left up to the developer.</div>Zjihttp://wiki.c2b2.columbia.edu/workbench/index.php?title=Style_Guide&diff=9228Style Guide2011-10-27T22:04:03Z<p>Zji: /* geWorkbench Developer Guide */</p>
<hr />
<div>== geWorkbench Developer Guide ==<br />
This document provides a style guide for developers of geWorkbench. The old content that has not been updated since 2005 may include something useful, so I keep them for now at the end the page, titled "Old Content".<br />
<br />
There are various good style guides out there on the Internet, this document is meant to focus on the issues that are more relevant to the current code base and development activity of geWorkbench. While it is not practical to enforce the style over the legacy code, new development should follow the guide line described here.<br />
* Remove dead code. This includes: unused local variables, unused private members, unused public members, out-of-date comments, unused classes/files, unless you have specific reason to expect to use it soon or as part of unfinished development.<br />
* If a local variable is adequate to serve your purpose, do not make it a member variable.<br />
* If a private member serves your purpose, do not make it public or default or protected.<br />
* If the class is intended to be extended, declare it as final - unless those require by geWorkbench framework not to be final.<br />
* If the method parameter is intended to be read only, declare it as final.<br />
* Name classes, variables, and methods what they really are or really do. If you cannot name your class as a noun, something is wrong with your design; if you cannot name your method as a verb, something is wrong with your design.<br />
* If one java file is over 1000 lines, the design deserves very careful scrutiny.<br />
* If class A refers to class B, and at the same time class B refers class A, the design needs scrutiny.<br />
* Refer to the object by a proper interface instead of implementation class when possible.<br />
<br />
=== Old Content ===<br />
=== Project Structure ===<br />
This section describes the directory structure of the project. The root directory structure contains the JBuilder and IDEA project and library files. It also contains this file, the <tt>java.policy</tt> file, and the <tt>build.xml</tt> ant build file.<br />
* <tt>_all</tt> - A folder for a placeholder module required for the IDEA IDE.<br />
* <tt>annotation</tt> - Marker annotations for various chip types.<br />
* <tt>components</tt> - The top-level directory for geWorkbench components.<br />
* <tt>data</tt> - Sample data files for the project.<br />
* <tt>lib</tt> - Library files for core geWorkbench.<br />
* <tt>plugins</tt> - Plugins for the Cytoscape package.<br />
* <tt>src</tt> - Source code for core geWorkbench.<br />
<br />
Each component is in a subdirectory of the <tt>components</tt> directory. It contains an IDEA <tt>.iml</tt> module file and it's directory structure is as follows:<br />
* <tt>lib</tt> - Library files depended on by this component.<br />
* <tt>src</tt> - Source code for the component.<br />
<br />
Note that the components can depend on the core classes (those defined in <tt>./src</tt>) and the core libraries (those defined in <tt>./lib</tt>). However, components cannot depend on each other, and the core classes cannot depend on components.<br />
<br />
=== Creating a New Component ===<br />
A new component should be added as a new subdirectory of <tt>components</tt>. The subdirectory should be given a simple, descriptive, lower-case name. It should contain <tt>src</tt> and <tt>lib</tt> directories. Most importantly, the component must not depend on the classes or libraries of any other component, nor should another component depend on it. Also, the core geWorkbench classes should not depend on its classes or libraries. The <tt>build.xml</tt> will enforce this, as will the IDEA project. However, the JBuilder project currently does not enforce this constraint, so be careful when using JBuilder.<br />
<br />
=== Coding Style ===<br />
The [http://java.sun.com/docs/codeconv/html/CodeConvTOC.doc.html coding standards] outlined by Sun are observed.<br />
Here are the coding standards that are particularly important to us:<br />
==== Capitalization ====<br />
Constants must be in all-capitals, with underscores between words:<br />
public static final int MAXIMUM_FILES = 100;<br />
<b>No</b> other identifiers may contain underscores but constants.<br />
Class, interface, enum and annotation names must be capitalized, with all subsequent words also capitalized:<br />
public class SampleClass extends AnotherSampleClass {<br />
Variable and member names must have their first letter lower-case, and subsequent words capitalized:<br />
private String fieldName;<br />
<br />
private abstract void processFile(File file);<br />
Some developers differentiate between method variables and class members by prepending <tt>m_</tt> or just <tt>_</tt> to member names.<br />
This is not a standard practice, so is not observed. Identifiers in property files are all lower-case with periods separating words:<br />
maximum.files=100<br />
Type wildcards in generics must be a single capital letter:<br />
public interface Generic&lt;T, S extends Serializable&gt; {<br />
==== Annotations ====<br />
Annotations can either appear on the same line as their associated declaration, or on the line before it:<br />
@Subscribe public void receive(Integer value) {<br />
<br />
@Script(dependencies = {STATE_UNINITIALIZED, STATE_COMPLETE}, result = STATE_INITIALIZED)<br />
public void initialize() {<br />
==== Variable Naming ====<br />
Variables should be given verbose names, even if they are only used in relatively small code blocks. Using the auto-complete functionality of modern IDEs makes compliance with this rule painless. Exceptions are simple index variables, such as those introduced in <code>for(;;)</code> statements:<br />
for (int i = 0; i < 100; i++) {<br />
==== Braces ====<br />
All <tt>if</tt>, <tt>while</tt> and similar block structures must be surrounded by braces, even if the body of the block consists of only one statement:<br />
if (index < 100) {<br />
System.out.println("index= " + index);<br />
}<br />
==== No Shortcuts ====<br />
Java provides some C-style shortcuts, such as the <code>++</code>, <code>+=</code> and <code>?:</code> operators. The <code>++</code>, <code>+=</code> operators can be used by themselves (for example, <code>++</code> is often used in a <code>for</code> statement) but they should not be included in other statements. The <code>?:</code> operator should only be used very sparingly, usually in statements that construct strings. Here is an example of a <b>bad</b> use of <code>++</code>:<br />
while (i < 100) {<br />
System.out.println("i= " + i++);<br />
}<br />
This is preferred:<br />
while (i < 100) {<br />
System.out.println("i= " + i);<br />
i++;<br />
}<br />
This is an acceptable use of <code>?:</code>:<br />
boolean available;<br />
...<br />
System.out.println("The file is " + (available ? "available" : "unavailable") + ".");<br />
However, it is a safe bet to never use <code>?:</code>.<br />
==== Tabs ====<br />
A tab-width of 4 should be used.<br />
<br />
=== Code Documentation ===<br />
Code must be documented using the [http://java.sun.com/j2se/javadoc/ Javadoc] standard.<br />
All classes, interfaces, enums and annotations must have an introductory Javadoc explaining its purpose.<br />
All public methods must also have explanatory Javadocs.<br />
Methods that perform non-trivial operations should have normal comments (not Javadoc) that explain the code.<br />
Such comments should precede the line (or lines) of code that they describe.<br />
For example:<br />
/**<br />
* Shuts down the componentRegistry (and terminates any pending aysnchronous dispatches).<br />
*/<br />
public void shutdown() {<br />
// Iterate through all active synch models<br />
Collection&lt;SynchModel&gt; models = synchModels.values();<br />
for (SynchModel synchModel : models) {<br />
// Shut down the synch model<br />
synchModel.shutdown();<br />
}<br />
}<br />
=== Packages ===<br />
Package names should follow the inverse-domain rule. If the domain of your organization is<br />
<code>subdomain.domain.tld</code>, then the package structure should be rooted at <code>tld.domain.subdomain</code>.<br />
Capital letters or underscore characters should never appear in package names.<br />
<br />
Otherwise, the organization of packages is left up to the developer.</div>Zjihttp://wiki.c2b2.columbia.edu/workbench/index.php?title=Style_Guide&diff=9227Style Guide2011-10-27T18:53:17Z<p>Zji: </p>
<hr />
<div>== geWorkbench Developer Guide ==<br />
This document provides a style guide for developers of geWorkbench. The old content that has not been updated since 2005 may include something useful, so I keep them for now at the end the page, titled "Old Content".<br />
<br />
There are various good style guides out there on the Internet, this document is meant to focus on the issues that are more relevant to the current code base and development activity of geWorkbench. While it is not practical to enforce the style over the legacy code, new development should follow the guide line described here.<br />
<br />
<br />
=== Old Content ===<br />
=== Project Structure ===<br />
This section describes the directory structure of the project. The root directory structure contains the JBuilder and IDEA project and library files. It also contains this file, the <tt>java.policy</tt> file, and the <tt>build.xml</tt> ant build file.<br />
* <tt>_all</tt> - A folder for a placeholder module required for the IDEA IDE.<br />
* <tt>annotation</tt> - Marker annotations for various chip types.<br />
* <tt>components</tt> - The top-level directory for geWorkbench components.<br />
* <tt>data</tt> - Sample data files for the project.<br />
* <tt>lib</tt> - Library files for core geWorkbench.<br />
* <tt>plugins</tt> - Plugins for the Cytoscape package.<br />
* <tt>src</tt> - Source code for core geWorkbench.<br />
<br />
Each component is in a subdirectory of the <tt>components</tt> directory. It contains an IDEA <tt>.iml</tt> module file and it's directory structure is as follows:<br />
* <tt>lib</tt> - Library files depended on by this component.<br />
* <tt>src</tt> - Source code for the component.<br />
<br />
Note that the components can depend on the core classes (those defined in <tt>./src</tt>) and the core libraries (those defined in <tt>./lib</tt>). However, components cannot depend on each other, and the core classes cannot depend on components.<br />
<br />
=== Creating a New Component ===<br />
A new component should be added as a new subdirectory of <tt>components</tt>. The subdirectory should be given a simple, descriptive, lower-case name. It should contain <tt>src</tt> and <tt>lib</tt> directories. Most importantly, the component must not depend on the classes or libraries of any other component, nor should another component depend on it. Also, the core geWorkbench classes should not depend on its classes or libraries. The <tt>build.xml</tt> will enforce this, as will the IDEA project. However, the JBuilder project currently does not enforce this constraint, so be careful when using JBuilder.<br />
<br />
=== Coding Style ===<br />
The [http://java.sun.com/docs/codeconv/html/CodeConvTOC.doc.html coding standards] outlined by Sun are observed.<br />
Here are the coding standards that are particularly important to us:<br />
==== Capitalization ====<br />
Constants must be in all-capitals, with underscores between words:<br />
public static final int MAXIMUM_FILES = 100;<br />
<b>No</b> other identifiers may contain underscores but constants.<br />
Class, interface, enum and annotation names must be capitalized, with all subsequent words also capitalized:<br />
public class SampleClass extends AnotherSampleClass {<br />
Variable and member names must have their first letter lower-case, and subsequent words capitalized:<br />
private String fieldName;<br />
<br />
private abstract void processFile(File file);<br />
Some developers differentiate between method variables and class members by prepending <tt>m_</tt> or just <tt>_</tt> to member names.<br />
This is not a standard practice, so is not observed. Identifiers in property files are all lower-case with periods separating words:<br />
maximum.files=100<br />
Type wildcards in generics must be a single capital letter:<br />
public interface Generic&lt;T, S extends Serializable&gt; {<br />
==== Annotations ====<br />
Annotations can either appear on the same line as their associated declaration, or on the line before it:<br />
@Subscribe public void receive(Integer value) {<br />
<br />
@Script(dependencies = {STATE_UNINITIALIZED, STATE_COMPLETE}, result = STATE_INITIALIZED)<br />
public void initialize() {<br />
==== Variable Naming ====<br />
Variables should be given verbose names, even if they are only used in relatively small code blocks. Using the auto-complete functionality of modern IDEs makes compliance with this rule painless. Exceptions are simple index variables, such as those introduced in <code>for(;;)</code> statements:<br />
for (int i = 0; i < 100; i++) {<br />
==== Braces ====<br />
All <tt>if</tt>, <tt>while</tt> and similar block structures must be surrounded by braces, even if the body of the block consists of only one statement:<br />
if (index < 100) {<br />
System.out.println("index= " + index);<br />
}<br />
==== No Shortcuts ====<br />
Java provides some C-style shortcuts, such as the <code>++</code>, <code>+=</code> and <code>?:</code> operators. The <code>++</code>, <code>+=</code> operators can be used by themselves (for example, <code>++</code> is often used in a <code>for</code> statement) but they should not be included in other statements. The <code>?:</code> operator should only be used very sparingly, usually in statements that construct strings. Here is an example of a <b>bad</b> use of <code>++</code>:<br />
while (i < 100) {<br />
System.out.println("i= " + i++);<br />
}<br />
This is preferred:<br />
while (i < 100) {<br />
System.out.println("i= " + i);<br />
i++;<br />
}<br />
This is an acceptable use of <code>?:</code>:<br />
boolean available;<br />
...<br />
System.out.println("The file is " + (available ? "available" : "unavailable") + ".");<br />
However, it is a safe bet to never use <code>?:</code>.<br />
==== Tabs ====<br />
A tab-width of 4 should be used.<br />
<br />
=== Code Documentation ===<br />
Code must be documented using the [http://java.sun.com/j2se/javadoc/ Javadoc] standard.<br />
All classes, interfaces, enums and annotations must have an introductory Javadoc explaining its purpose.<br />
All public methods must also have explanatory Javadocs.<br />
Methods that perform non-trivial operations should have normal comments (not Javadoc) that explain the code.<br />
Such comments should precede the line (or lines) of code that they describe.<br />
For example:<br />
/**<br />
* Shuts down the componentRegistry (and terminates any pending aysnchronous dispatches).<br />
*/<br />
public void shutdown() {<br />
// Iterate through all active synch models<br />
Collection&lt;SynchModel&gt; models = synchModels.values();<br />
for (SynchModel synchModel : models) {<br />
// Shut down the synch model<br />
synchModel.shutdown();<br />
}<br />
}<br />
=== Packages ===<br />
Package names should follow the inverse-domain rule. If the domain of your organization is<br />
<code>subdomain.domain.tld</code>, then the package structure should be rooted at <code>tld.domain.subdomain</code>.<br />
Capital letters or underscore characters should never appear in package names.<br />
<br />
Otherwise, the organization of packages is left up to the developer.</div>Zjihttp://wiki.c2b2.columbia.edu/workbench/index.php?title=Developers&diff=7060Developers2010-10-23T15:00:00Z<p>Zji: </p>
<hr />
<div>{{DevelopersTopNav}}<br />
<br />
geWorkbench is an open source Java-based platform and contributions by members of the community are welcome and encouraged. The latest code under development can be found at NCI's subversion server, https://ncisvn.nci.nih.gov/svn/geworkbench/trunk/geworkbench/. Anonymous read access is supported for all the code.<br />
<br />
<br />
Development in geWorkbench takes place along 2 lines:<br />
* <u>'''geWorkbench core'''</u>: this portion of the code includes mainly 7 groups of packages:<br />
# ''engine'', which implements services related to the geWorkbench component architecture framework (e.g., plugin instantiation and visual layout, message delivery, component registry management, etc)<br />
# ''bison'' ('''B'''iomedical '''I'''nformatics '''S'''tructured '''ON'''tology) which contains the definition of the bioinformatics data types which form the basis of communication between the geWorkbench plugins.<br />
# ''builtin'', supporting the internal execution and coordination of the core process, especially the project panel<br />
# ''parsers'', parsing supports for input data format<br />
# ''events'', event classes used by communication between all components and the core<br />
# ''util'', all the utility libraries<br />
# ''others'', including package "analysis" providing abstract for analyses and package "algorithm" used by some classification algorithm. Both contains a small number of classes.<br />
* <u>'''geWorkbench plugins'''</u>: this portion of the source tree contains the code for the various application plugin components (sample code for creating a simple plugin can be found [[A_Simple_Plugin |here]])<br />
<br />
There are no restrictions on who can develop a new component for geWorkbench. You can work against the development version or a release version of the geWorkbench core. To contribute your component to geWorkbench code, you need write access to the subversion server. Please contact us for the procedure.<br />
Contributions to the geWorkbench core packages are more controlled in order to avoid changes that may adversely affect large numbers of plugins.</div>Zjihttp://wiki.c2b2.columbia.edu/workbench/index.php?title=Developers&diff=6738Developers2010-06-29T14:06:28Z<p>Zji: </p>
<hr />
<div>{{DevelopersTopNav}}<br />
<br />
geWorkbench is an open source Java-based platform and contributions by members of the community are welcome and encouraged. The latest code under development can be found at NCI's subversion server, https://ncisvn.nci.nih.gov/svn/geworkbench/trunk/geworkbench/. Anonymous read access is supported for all the code.<br />
<br />
<br />
Development in geWorkbench takes place along 2 parallel axes:<br />
* <u>'''geWorkbench core'''</u>: this portion of the code includes mainly 7 groups of packages:<br />
# ''engine'', which implements services related to the geWorkbench component architecture framework (e.g., plugin instantiation and visual layout, message delivery, component registry management, etc)<br />
# ''bison'' ('''B'''iomedical '''I'''nformatics '''S'''tructured '''ON'''tology) which contains the definition of the bioinformatics data types which form the basis of communication between the geWorkbench plugins.<br />
# ''analysis'', providing abstract for various analyses and processing<br />
# ''builtin'', supporting the internal execution and coordination of the core process, especially the project panel<br />
# ''components'', parsers and supports for input data format<br />
# ''events'', event classes used by communication between all components and the core<br />
# ''util'', all the utility libraries<br />
* <u>'''geWorkbench plugins'''</u>: this portion of the source tree contains the code for the various application plugin components (sample code for creating a simple plugin can be found [[A_Simple_Plugin |here]])<br />
<br />
There are no restrictions on who can develop a new component for geWorkbench. You can work against the development version or a release version of the geWorkbench core. To contribute your component to geWorkbench code, you need write access to the subversion server. Please contact us for the procedure.<br />
Contributions to the geWorkbench core packages are more controlled in order to avoid changes that may adversely affect large numbers of plugins.</div>Zjihttp://wiki.c2b2.columbia.edu/workbench/index.php?title=Plugins&diff=6319Plugins2010-06-10T21:46:44Z<p>Zji: </p>
<hr />
<div>__NOEDITSECTION__<br />
The geWorkbench platform employs a component repository infrastructure to manage a large collection of pluggable components that can be used to customize the application's graphical user interface. This (ever growing) list of plug-in components covers a wide range of fucntionality for a number of different genomic data modalities.<br />
<br />
The Status of the pluggable components below is defined as:<br />
<br />
<br />
{|style="border: 1px solid lightGray"<br />
!Status||Comment<br />
|-<br />
|-<br />
|width="120"|(a) Released||This plugin is part of the latest geWorkbench version.<br />
|-<br />
|width="120"|(b) Development||This plugin is currently actively being developed.<br />
|-<br />
|-<br />
|}<br />
<br />
<br />
<br />
__TOC__<br />
<br />
<br />
==Analysis==<br />
<br />
{|style="border: 1px solid lightGray"<br />
!Plugin||Status||Description<br />
|-<br />
|-<br />
|width="150"|ANOVA||Released||Analysis of Variance - detection of significant differences in expression between more than two groups. ([[media:T_ANOVA_ColorMosaic.png|Screenshot]])<br />
|-<br />
|-<br />
|width="150"|Evidence Integration||Development||A sequence and structure-based approach for functional annotation and protein-protein interaction analysis.<br />
|-<br />
|-<br />
|width="150"|GSEA||Development||The Gene Set Enrichment Analysis determines whether an a priori defined set of genes shows statistically significant differences between two phenotypes.<br />
|-<br />
|-<br />
|width="150"|Hierarchical Clustering||Released||Clustering of markers and microarrays into hierarchical binary trees. The resulting structures can be visualized in the Dendrogram plugin. ([[media:T_HC_Dendrogram_display.png|Screenshot]])<br />
|-<br />
|-<br />
|width="150"|KNN||Released||k-Nearest Neighbors analysis (a GenePattern component).<br />
|-<br />
|-<br />
|width="150"|Mark-Us||Released||Assesses the biochemical function for a given protein structure. ([[media:T_MarkUs_Web_result.png|Screenshot]])<br />
|-<br />
|-<br />
|width="150"|MatrixReduce||Released||Transcription Factor binding motifs. ([[media:T_MatrixREDUCE_PSAM_view.png|Screenshot]])<br />
|-<br />
|-<br />
|width="150"|MEDUSA||Development||The Motif Element Detection Using Sequence Agglomeration is an integrative method for learning motif models of transcription factor binding sites by incorporating promoter sequence and gene expression data (Leslie Lab, MSKCC).<br />
|-<br />
|-<br />
|width="150"|MRA||Released||The Master Regulator Analysis combines regulatory information from interaction networks with differential expression analysis. ([[media:MRA_viewer_full.png|Screenshot]])<br />
|-<br />
|-<br />
|width="150"|PCA||Released||Principal Component Analysis (a GenePattern component).<br />
|-<br />
|-<br />
|width="150"|Pudge||Released||Computational protein structure prediction using sequence homology. It integrates tools used at different stages of the structural prediction process. ([[media:T_Pudge_Parameters.png|Screenshot Parameters]], [[media:T_Pudge_Alignment_example.png|Screenshot Result]])<br />
|- <br />
|-<br />
|width="150"|SkyBase||Released||Database of protein structure models produced by SkyLine based on structures solved by the NESG structural genomics consortium.<br />
|- <br />
|-<br />
|width="150"|SkyLine||Released||Automated high-throughput pipeline for reverse homology-based comparative protein structure modeling based on the input template structure.<br />
|- <br />
|-<br />
|width="150"|SOM||Released||Clustering of markers using Self Organizing Maps. The resulting clusters can be visualized in the SOM Clusters Viewer plugin. ([[media:T_SOM_result.png|Screenshot]])<br />
|-<br />
|-<br />
|width="150"|SVM 3.0||Released||The Support Vector Machine is a supervised classification method that computes a maximal separating hyperplane between the expression vectors of different classes or phenotypes (a GenePattern component).<br />
|-<br />
|-<br />
|width="150"|T-Test||Released||Identification of markers with statistically significant differential expression between sets of microarrays. ([[media:T_t-test_volcano_BCELL_webm_qldm.png|Screenshot Plot]], [[media:T_t-test_colormosaic_BCELL_webm_qldm.png|Screenshot Mosaic]])<br />
|-<br />
|-<br />
|width="150"|Weighted Voting||Released||Weighted Voting Analysis (a GenePattern component).<br />
|-<br />
|-<br />
|}<br />
<br />
<br />
==Annotation==<br />
<br />
{|style="border: 1px solid lightGray"<br />
!Plugin||Status||Description<br />
|-<br />
|-<br />
|width="150"|caScript||Development||An Editor.<br />
|-<br />
|-|width="150"|Dataset Annotation||Released||Free text format box used to annotate data, images and results. Such annotations persist application invocations and can be used as an online notebook.<br />
|-<br />
|-<br />
|width="150"|Dataset History||Released||Log of data transformations induced by data-modifying operations.<br />
|-<br />
|-<br />
|width="150"|Experiment Information||Released||Microarray machine parameters used in an experiment run. If available, high-level experiment information (e.g., purpose of of experiment) are also displayed.<br />
|-<br />
|-<br />
|width="150"|Gene Ontology Enrichment||Released||Enrichment analysis of selected groups of genes against Gene Ontology (http://www.geneontology.org) annotations. ([[media:T_GO_Terms_TableBrowser_Gene_Detail.png|Screenshot]])<br />
|-<br />
|-<br />
|width="150"|Marker Annotations||Released||Retrieval of gene and pathway information for markers on a microarray (caBIO Pathways/Cancer Gene Index); it includes visualization of BioCarta pathway diagrams. ([[media:GeWB_Marker_Annotations.png|Screenshot Table]], [[media:GeWB_Marker_Annotations_Pathway.png|Screenshot BioCarta]], [[media:GeWB_Marker_Annotations_CGI.png|Screenshot CGI]])<br />
|-<br />
|-<br />
|}<br />
<br />
<br />
==Data Filtering==<br />
<br />
{|style="border: 1px solid lightGray"<br />
!Plugin||Status||Description<br />
|-<br />
|-<br />
|width="150"|Affy Detection Call Filter||Released||Filtering of measurements based on the value of their "detection call" attribute ''(Affymetrix data only)'' .<br />
|-<br />
|-<br />
|width="150"|Deviation Filter||Released||Filtering of markers with low dynamic range.<br />
|-<br />
|-<br />
|width="150"|Expression Threshold Filter||Released||Elimination of measurements that fall outside a range of explression values.<br />
|-<br />
|-<br />
|width="150"|2-channel Threshold Filter||Released||Same as "Expression Threshold" filter but different threshold ranges can be specified for each channel ''(GenePix data only)''.<br />
|-<br />
|-<br />
|width="150"|Genepix Flag Filter||Released||Filtering of measurements based on the value of their "Flags" attribute ''(GenePix data only)''.<br />
|-<br />
|-<br />
|width="150"|Missing Value Filter||Released||Discards all markers that have missing measurements in more than a user specified number N of microarrays.<br />
|-<br />
|-<br />
|}<br />
<br />
<br />
==Data Management==<br />
<br />
{|style="border: 1px solid lightGray"<br />
!Plugin||Status||Description<br />
|- <br />
|-<br />
|width="150"|Arrays/Phenotypes||Released||Definition of data views consisting of microarray subgroups. The views control the amount of data displayed. ([[media:T_t-test_Arrays_case-set_BCELL_webm_qldm.png|Screenshot]])<br />
|-<br />
|-<br />
|width="150"|caArray||Released||Search and download of gene expression data from instances of caArray (NCI microarray database product). ([[media:T_caArray_A549_arrays.png|Screenshot]])<br />
|-<br />
|-<br />
|width="150"|Markers||Released||Definition of data views consisting of marker subgroups. The views control the amount of data displayed. ([[media:Select_marker_sets.png|Screenshot]])<br />
|- <br />
|-<br />
|width="150"|Project Folders||Released||Manages projects and workspaces of the user. ([[media:T_ANOVA_Saved_Color_Mosaic_View.png|Screenshot]])<br />
|-<br />
|-<br />
|}<br />
<br />
<br />
==File Import==<br />
<br />
{|style="border: 1px solid lightGray"<br />
!Plugin||Status||Description<br />
|-<br />
|-<br />
|width="150"|Affymetrix CEL||Released||Loads Affymetrix probe CELl intensity files ("*.cel").<br />
|-<br />
|-<br />
|width="150"|Affymetrix File Matrix||Released|| Loads Affymetrix EXPperiment files ("*.exp").<br />
|-<br />
|-<br />
|width="150"|Affymetrix MAS5/GCOS||Released|| Loads output files from the GeneChip Operating Software formerly known as MAS5 Statistical algorithm (several different file extension).<br />
|-<br />
|-<br />
|width="150"|FASTA Format||Released||Loads files that are in FASTA format ("*.fasta" and "*.txt").<br />
|-<br />
|-<br />
|width="150"|Genepix File Format||Released||Loads files in GenePix Result format ("*.gpr").<br />
|-<br />
|-<br />
|width="150"|PDB Structure Format||Released||Loads files in the Protein Data Base format ("*.pdb")<br />
|-<br />
|-<br />
|width="150"|Tab-delimited (RMA Express Format)||Released||Loads tab-delimited files from the Robust Multichip Analysis ("*.txt")<br />
|-<br />
|-<br />
|}<br />
<br />
<br />
==Menu Tools==<br />
<br />
{|style="border: 1px solid lightGray"<br />
!Plugin||Status||Description<br />
|-<br />
|-<br />
|width="150"|CCM||Released||The Component Configuration Manager allows users to manage plugins dynamically at any given time in the application environment. ([[media:T_Component_Configuration_Manager.png|Screenshot]])<br />
|-<br />
|-<br />
|width="150"|genSpace||Released||It logs information about the analysis tools used in geWorkbench in order to enable collaboration support for the geWorkbench users.<br />
|-<br />
|-<br />
|width="150"|Online Help||Released||geWorkbench Online Help uses the Java help 2.0 system to provide real-time help on component questions.<br />
|-<br />
|-<br />
|width="150"|Preferences||Released||Allows users to predefine a few basic visual settings and choose a Text Editor.<br />
|-<br />
|-<br />
|width="150"|Version Information||Released||Provides basic information about the currently installed user version of geWorkbench.<br />
|-<br />
|-<br />
|width="150"|Welcome Screen||Released||Introduction to geWorkbench during the initial opening of the application.<br />
|-<br />
|-<br />
|}<br />
<br />
<br />
==Network Generation==<br />
<br />
{|style="border: 1px solid lightGray"<br />
!Plugin||Status||Description<br />
|-<br />
|-<br />
|width="150"|ARACNe||Released||The Algorithm for the Reconstruction of Accurate Cellular Networks analyses large amount of microarray data (typically 100-500 microarrays) to reverse engineer underlying gene regulatory networks. ([[media:T_ARACNE_result1.png|Screenshot]])<br />
|-<br />
|-<br />
|width="150"|Cancer GEMS||Development||Interface to the NCI Cancer Genetic Markers of Susceptibility project.<br />
|-<br />
|-<br />
|width="150"|CNKB||Released||The Cellular Networks Knowledge Base queries an in-house repository of locally generated B-cell interaction network data and information from external databases in order to build a network of interactions for selected genes. ([[media:T_CNKB_ProtDNA_confidence75.png|Screenshot Throttle Graph]], [[media:T_CNKB_10at75_Cytoscape.png|Screenshot Network]])<br />
|-<br />
|-<br />
|width="150"|Cytoscape||Released||Visualization of gene regulatory network created in Reverse Engineering using [http://www.cytoscape.org/ Cytoscape 1.0]. ([[media:T_ARACNE_result1.png|Screenshot]])<br />
|-<br />
|-<br />
|width="150"|MINDy||Released||The Modulator Inference by Network Dynamics algorithm extends ARACNe to include detecting the influence of modulators of transcription factor activity.<br />
|-<br />
|-<br />
|width="150"|NetBoost||Development||NetBoost is a network characterization algorithm.<br />
|-<br />
|}<br />
<br />
<br />
==Normalization==<br />
<br />
{|style="border: 1px solid lightGray"<br />
!Plugin||Status||Description<br />
|-<br />
|-<br />
|width="150"|Array-Based Centering||Released||Subtraction of the mean or median measurement of a microarray from every measurement in that microarray.<br />
|-<br />
|-<br />
|width="150"|Housekeeping Normalizer||Released|| Normalization of all measurements in a microarray through division by the average expression value of a (user defined) set of housekeeping genes.<br />
|-<br />
|-<br />
|width="150"|Log2 Normalizer||Released||Applies a log2 transformation to all measurements in a microarray.<br />
|-<br />
|-<br />
|width="150"|Marker-Based Centering||Released||Subtraction of the mean or median measurement of a marker profile from every measurement in the profile.<br />
|-<br />
|-<br />
|width="150"|Mean-Variance Normalizer||Released||Transformation of expression measurements to standard units: for every marker, the mean measurement of the marker profile (across all microarrays in an experiment) is subtracted from each measurement in the profile and the resulting value is divided by the standard deviation of the profile.<br />
|-<br />
|-<br />
|width="150"|Missing Value Normalizer||Released||Replacement of missing values with consensus values.<br />
|-<br />
|-<br />
|width="150"|Quantile Normalizer||Released|| Expression measurements in each microarray are adjusted so that the distribution of values is the same across all microarrays in an experiment.<br />
|-<br />
|-<br />
|width="150"|Threshold Normalizer||Released||Adjustment of values that fall outside a user-specified threshold.<br />
|-<br />
|-<br />
|}<br />
<br />
<br />
== Sequence Analysis & Visualization ==<br />
<br />
{|style="border: 1px solid lightGray"<br />
!Plugin||Status||Description<br />
|-<br />
|-<br />
|width="150"|Alignment Results||Released||It parses and displays the results of sequence similarity searches which were run on the NCBI BLAST service. ([[media:T_SequenceAlignment_BLAST_results.png|Screenshot]])<br />
|-<br />
|-<br />
|width="150"|Pattern Discovery||Released|| Discovery of sequence motifs in sets of DNA and protein sequences. ([[media:T_PatternDiscovery_Params_Basic_histone_result_exact_seqs.png|Screenshot]])<br />
|-<br />
|-<br />
|width="150"|Position Histogram ||Released|| Visualization of results from the Pattern Discovery plugin. Motif/pattern support is plotted against relative sequence position of the motif match. ([[media:T_PatternDiscovery_Histones_Result_exact_Position_Histogram.png|Screenshot]])<br />
|-<br />
|-<br />
|width="150"|Promoter Analysis||Released||Identification of putative transcription factor binding sites in DNA sequences. The analysis use the profiles in the [http://jaspar.cgb.ki.se/cgi-bin/jaspar_db.pl JASPAR Transcription Factor Binding Profile Database]. ([[media:T_Promoter_CDH2_AP2_2000updn_setup_logo.png|Screenshot Logo]], [[media:T_Promoter_CDH2_AP2_2000updn_scan.png|Screenshot Sequence 1]], [[media:T_Promoter_CDH2_AP2_2000updn_scan_fullseq.png|Screenshot Sequence 2]])<br />
|-<br />
|-<br />
|width="150"|Sequence Alignment||Released||Run jobs on the NCBI BLAST servers directly within geWorkbench. <br />
|-<br />
|-<br />
|width="150"|Sequence Panel ||Released|| Visualization of results from the Pattern Discovery plugin, displaying the motif match location over each sequence from the input data set.<br />
|-<br />
|-<br />
|width="150"|Sequence Retriever||Released||Retrieve sequences for annotated markers from Santa Cruz (Nucleotides) and EBI (Proteins). ([[media:T_SequenceRetriever_AfterRetrieval.png|Screenshot]])<br />
|-<br />
|-<br />
|}<br />
<br />
<br />
==Visualization==<br />
<br />
{|style="border: 1px solid lightGray"<br />
!Plugin||Status||Description<br />
|-<br />
|-<br />
|width="150"|Analysis Panel||Released||Framework to support numerous, individually loadable analysis methods. <br />
|-<br />
|-<br />
|width="150"|ANOVA Tabular Viewer||Released||Displays the results of ANOVA analysis of gene expression data in tabular format. ([[media:T_ANOVA_Tabular_Viewer.png|Screenshot]])<br />
|-<br />
|-<br />
|width="150"|CEL Image Viewer||Released||Visualization of data in Affymetrix CEL files. ([[media:T_CEL_viewer.png|Screenshot]])<br />
|-<br />
|- <br />
|width="150"|Color Mosaic||Released||Heat maps for microarray expression data, organized by phenotypic or gene groupings. ([[media:GeWB_Color_Mosaic_Viewer.png|Screenshot]])<br />
|-<br />
|-<br />
|width="150"|Dendrogram||Released||Tree-structured diagrams reflecting the results of hierarchical clustering analysis. ([[media:T_HC_Dendrogram_display.png|Screenshot]])<br />
|-<br />
|-<br />
|width="150"|Evidence Integration Viewer||Development||Displays the results of the Evidence Integration analysis.<br />
|- <br />
|-<br />
|width="150"|Expression Profiles||Released||Line graph of genes expression profiles across several arrays/ hybridizations. ([[media:GeWB_Expression_Profile_2markers.png|Screenshot]])<br />
|- <br />
|-<br />
|width="150"|Expression Value Distribution||Released||Distribution plot of marker expression values across one or more microarrays. ([[media:T_EVD.png|Screenshot]])<br />
|-<br />
|-<br />
|width="150"|GeneWays||Released||An essential component needed to display elements in Cytoscape and ARACNe.<br />
|-<br />
|-<br />
|width="150"|GO Terms Viewer||Released||Displays the results of Gene Ontology Enrichment Analysis. ([[media:T_GO_Terms_TableBrowser_Gene_Detail.png|Screenshot]])<br />
|- <br />
|- <br />
|width="150"|Image Viewer||Released||Visualization of screenshots saved within geWorkbench (e.g. dendrograms).<br />
|- <br />
|- <br />
|width="150"|Jmol||Released|| Visualization of 3D protein structures from PDB files. ([[media:T_JMOL_Viewer.png|Screenshot]])<br />
|- <br />
|-<br />
|width="150"|Mark-Us Browser||Released|| Displays the results of a Mark-Us analysis. ([[media:T_MarkUs_Web_result.png|Screenshot]])<br />
|- <br />
|-<br />
|width="150"|MatrixReduce||Released||Visualization of MatrixReduce calculations using logo, chromosomal and tabular displays.<br />
|- <br />
|-<br />
|width="150"|MEDUSA Viewer||Development||Displays the results of a MEDUSA analysis.<br />
|- <br />
|-<br />
|width="150"|Microarray Viewer||Released||Color-gradient representation of gene expression values. ([[media:GeWB_Microarray_Viewer.png|Screenshot]])<br />
|- <br />
|-<br />
|width="150"|MINDy Viewer||Released||The results of a MINDy calculation are presented in several different tabular displays and a heat map.<br />
|- <br />
|-<br />
|width="150"|MRA Viewer||Released||Displays the results of the MRA in tablular and graphical form. ([[media:MRA_viewer_full.png|Screenshot]])<br />
|- <br />
|-<br />
|width="150"|NetBoost Viewer||Development||Displays a Boosting Iteration Graph, Confusion Matrix and Score Table from NetBoost Analysis.<br />
|- <br />
<br />
|-<br />
|width="150"|Normalization Panel||Released||Framework to support numerous, individually loadable normalization components.<br />
|-<br />
|-<br />
|width="150"|PCA Viewer||Released||Displays PCA results.<br />
|-<br />
|-<br />
|width="150"|Pudge Browser||Released||Visualization of Pudge results. ([[media:T_Pudge_Parameters.png|Screenshot Parameters]], [[media:T_Pudge_Alignment_example.png|Screenshot Result]])<br />
|- <br />
|-<br />
|width="150"|Scatter Plot||Released||Pairwise (array vs. array and marker vs. marker) comparison and plotting of expression values. ([[media:GeWB_Scatter_Plot_array_vs_array.png|Screenshot Array]], [[media:GeWB_Scatter_Plot_marker_vs_marker.png|Screenshot Marker]])<br />
|- <br />
|-<br />
|width="150"|SkyBase Viewer||Released||Displays the results from the SkyBase search.<br />
|- <br />
|-<br />
|width="150"|SkyLine Output All||Released||Displays all models from the Skyline modeling.<br />
|- <br />
|-<br />
|width="150"|SkyLine Output Each||Released||Displays each model from the Skyline modeling.<br />
|- <br />
|-<br />
|width="150"|SkyLine Contour||Development||A 2D dominance-based visualization of query results.<br />
|- <br />
|-<br />
|width="150"|SOM Clusters Viewer||Released||Visualization of gene clusters produced by the self-organizing maps analysis. ([[media:T_SOM_result.png|Screenshot]]) <br />
|-<br />
|-<br />
|width="150"|SVM Viewer||Released||Visualizes results obtained from classifying samples based on SVMs generated using the Gene Pattern v3 SVM service. <br />
|- <br />
|-<br />
|width="150"|Tabular Microarray Viewer||Released||Spreadsheet view of all expression measurement in an experiment, one row per individual marker/probe and one column per microarray. ([[media:GeWB_Tabular_Microarray_Viewer.png|Screenshot]])<br />
|-<br />
|-<br />
|width="150"| Volcano Plot||Released|| Visualize fold-change vs significance (P-value) for t-test results. ([[media:T_t-test_volcano_BCELL_webm_qldm.png|Screenshot]])<br />
|- <br />
|-<br />
|}</div>Zjihttp://wiki.c2b2.columbia.edu/workbench/index.php?title=Plugins&diff=6317Plugins2010-06-10T21:43:44Z<p>Zji: </p>
<hr />
<div>__NOEDITSECTION__<br />
The geWorkbench platform employs a component repository infrastructure to manage a large collection of pluggable components that can be used to customize the application's graphical user interface. This (ever growing) list of plug-in components covers a wide range of fucntionality for a number of different genomic data modalities.<br />
<br />
The Status of the pluggable components below is defined as:<br />
<br />
<br />
{|style="border: 1px solid lightGray"<br />
!Status||Comment<br />
|-<br />
|-<br />
|width="120"|(a) Released||This plugin is part of the latest geWorkbench version.<br />
|-<br />
|width="120"|(b) Development||This plugin is currently actively being developed.<br />
|-<br />
|-<br />
|}<br />
<br />
<br />
<br />
__TOC__<br />
<br />
<br />
==Analysis==<br />
<br />
{|style="border: 1px solid lightGray"<br />
!Plugin||Status||Description<br />
|-<br />
|-<br />
|width="150"|ANOVA||Released||Analysis of Variance - detection of significant differences in expression between more than two groups. ([[media:T_ANOVA_ColorMosaic.png|Screenshot]])<br />
|-<br />
|-<br />
|width="150"|Evidence Integration||Development||A sequence and structure-based approach for functional annotation and protein-protein interaction analysis.<br />
|-<br />
|-<br />
|width="150"|GSEA||Development||The Gene Set Enrichment Analysis determines whether an a priori defined set of genes shows statistically significant differences between two phenotypes.<br />
|-<br />
|-<br />
|width="150"|Hierarchical Clustering||Released||Clustering of markers and microarrays into hierarchical binary trees. The resulting structures can be visualized in the Dendrogram plugin. ([[media:T_HC_Dendrogram_display.png|Screenshot]])<br />
|-<br />
|-<br />
|width="150"|KNN||Released||k-Nearest Neighbors analysis (a GenePattern component).<br />
|-<br />
|-<br />
|width="150"|Mark-Us||Released||Assesses the biochemical function for a given protein structure. ([[media:T_MarkUs_Web_result.png|Screenshot]])<br />
|-<br />
|-<br />
|width="150"|MatrixReduce||Released||Transcription Factor binding motifs. ([[media:T_MatrixREDUCE_PSAM_view.png|Screenshot]])<br />
|-<br />
|-<br />
|width="150"|MEDUSA||Development||The Motif Element Detection Using Sequence Agglomeration is an integrative method for learning motif models of transcription factor binding sites by incorporating promoter sequence and gene expression data (Leslie Lab, MSKCC).<br />
|-<br />
|-<br />
|width="150"|MRA||Released||The Master Regulator Analysis combines regulatory information from interaction networks with differential expression analysis. ([[media:MRA_viewer_full.png|Screenshot]])<br />
|-<br />
|-<br />
|width="150"|PCA||Released||Principal Component Analysis (a GenePattern component).<br />
|-<br />
|-<br />
|width="150"|Pudge||Released||Computational protein structure prediction using sequence homology. It integrates tools used at different stages of the structural prediction process. ([[media:T_Pudge_Parameters.png|Screenshot Parameters]], [[media:T_Pudge_Alignment_example.png|Screenshot Result]])<br />
|- <br />
|-<br />
|width="150"|SkyBase||Released||Database of protein structure models produced by SkyLine based on structures solved by the NESG structural genomics consortium.<br />
|- <br />
|-<br />
|width="150"|SkyLine||Released||Automated high-throughput pipeline for reverse homology-based comparative protein structure modeling based on the input template structure.<br />
|- <br />
|-<br />
|width="150"|SOM||Released||Clustering of markers using Self Organizing Maps. The resulting clusters can be visualized in the SOM Clusters Viewer plugin. ([[media:T_SOM_result.png|Screenshot]])<br />
|-<br />
|-<br />
|width="150"|SVM 3.0||Released||The Support Vector Machine is a supervised classification method that computes a maximal separating hyperplane between the expression vectors of different classes or phenotypes (a GenePattern component).<br />
|-<br />
|-<br />
|width="150"|T-Test||Released||Identification of markers with statistically significant differential expression between sets of microarrays. ([[media:T_t-test_volcano_BCELL_webm_qldm.png|Screenshot Plot]], [[media:T_t-test_colormosaic_BCELL_webm_qldm.png|Screenshot Mosaic]])<br />
|-<br />
|-<br />
|width="150"|Weighted Voting||Released||Weighted Voting Analysis (a GenePattern component).<br />
|-<br />
|-<br />
|}<br />
<br />
<br />
==Annotation==<br />
<br />
{|style="border: 1px solid lightGray"<br />
!Plugin||Status||Description<br />
|-<br />
|-<br />
|width="150"|caScript||Development||An Editor.<br />
|-<br />
|-|width="150"|Dataset Annotation||Released||Free text format box used to annotate data, images and results. Such annotations persist application invocations and can be used as an online notebook.<br />
|-<br />
|-<br />
|width="150"|Dataset History||Released||Log of data transformations induced by data-modifying operations.<br />
|-<br />
|-<br />
|width="150"|Experiment Information||Released||Microarray machine parameters used in an experiment run. If available, high-level experiment information (e.g., purpose of of experiment) are also displayed.<br />
|-<br />
|-<br />
|width="150"|Gene Ontology Enrichment||Released||Enrichment analysis of selected groups of genes against Gene Ontology (http://www.geneontology.org) annotations. ([[media:T_GO_Terms_TableBrowser_Gene_Detail.png|Screenshot]])<br />
|-<br />
|-<br />
|width="150"|Marker Annotations||Released||Retrieval of gene and pathway information for markers on a microarray (caBIO Pathways/Cancer Gene Index); it includes visualization of BioCarta pathway diagrams. ([[media:GeWB_Marker_Annotations.png|Screenshot Table]], [[media:GeWB_Marker_Annotations_Pathway.png|Screenshot BioCarta]], [[media:GeWB_Marker_Annotations_CGI.png|Screenshot CGI]])<br />
|-<br />
|-<br />
|}<br />
<br />
<br />
==Data Filtering==<br />
<br />
{|style="border: 1px solid lightGray"<br />
!Plugin||Status||Description<br />
|-<br />
|-<br />
|width="150"|Affy Detection Call Filter||Released||Filtering of measurements based on the value of their "detection call" attribute ''(Affymetrix data only)'' .<br />
|-<br />
|-<br />
|width="150"|Deviation Filter||Released||Filtering of markers with low dynamic range.<br />
|-<br />
|-<br />
|width="150"|Expression Threshold Filter||Released||Elimination of measurements that fall outside a range of explression values.<br />
|-<br />
|-<br />
|width="150"|2-channel Threshold Filter||Released||Same as "Expression Threshold" filter but different threshold ranges can be specified for each channel ''(GenePix data only)''.<br />
|-<br />
|-<br />
|width="150"|Genepix Flag Filter||Released||Filtering of measurements based on the value of their "Flags" attribute ''(GenePix data only)''.<br />
|-<br />
|-<br />
|width="150"|Missing Value Filter||Released||Discards all markers that have missing measurements in more than a user specified number N of microarrays.<br />
|-<br />
|-<br />
|}<br />
<br />
<br />
==Data Management==<br />
<br />
{|style="border: 1px solid lightGray"<br />
!Plugin||Status||Description<br />
|- <br />
|-<br />
|width="150"|Arrays/Phenotypes||Released||Definition of data views consisting of microarray subgroups. The views control the amount of data displayed. ([[media:T_t-test_Arrays_case-set_BCELL_webm_qldm.png|Screenshot]])<br />
|-<br />
|-<br />
|width="150"|caArray||Released||Search and download of gene expression data from instances of caArray (NCI microarray database product). ([[media:T_caArray_A549_arrays.png|Screenshot]])<br />
|-<br />
|-<br />
|width="150"|Markers||Released||Definition of data views consisting of marker subgroups. The views control the amount of data displayed. ([[media:Select_marker_sets.png|Screenshot]])<br />
|- <br />
|-<br />
|width="150"|Project Folders||Released||Manages projects and workspaces of the user. ([[media:T_ANOVA_Saved_Color_Mosaic_View.png|Screenshot]])<br />
|-<br />
|-<br />
|}<br />
<br />
<br />
==File Import==<br />
<br />
{|style="border: 1px solid lightGray"<br />
!Plugin||Status||Description<br />
|-<br />
|-<br />
|width="150"|Affymetrix CEL||Released||Loads Affymetrix probe CELl intensity files ("*.cel").<br />
|-<br />
|-<br />
|width="150"|Affymetrix File Matrix||Released|| Loads Affymetrix EXPperiment files ("*.exp").<br />
|-<br />
|-<br />
|width="150"|Affymetrix MAS5/GCOS||Released|| Loads output files from the GeneChip Operating Software formerly known as MAS5 Statistical algorithm (several different file extension).<br />
|-<br />
|-<br />
|width="150"|FASTA Format||Released||Loads files that are in FASTA format ("*.fasta" and "*.txt").<br />
|-<br />
|-<br />
|width="150"|Genepix File Format||Released||Loads files in GenePix Result format ("*.gpr").<br />
|-<br />
|-<br />
|width="150"|PDB Structure Format||Released||Loads files in the Protein Data Base format ("*.pdb")<br />
|-<br />
|-<br />
|width="150"|Tab-delimited (RMA Express Format)||Released||Loads tab-delimited files from the Robust Multichip Analysis ("*.txt")<br />
|-<br />
|-<br />
|}<br />
<br />
<br />
==Menu Tools==<br />
<br />
{|style="border: 1px solid lightGray"<br />
!Plugin||Status||Description<br />
|-<br />
|-<br />
|width="150"|CCM||Released||The Component Configuration Manager allows users to manage plugins dynamically at any given time in the application environment. ([[media:T_Component_Configuration_Manager.png|Screenshot]])<br />
|-<br />
|-<br />
|width="150"|genSpace||Released||It logs information about the analysis tools used in geWorkbench in order to enable collaboration support for the geWorkbench users.<br />
|-<br />
|-<br />
|width="150"|Online Help||Released||geWorkbench Online Help uses the Java help 2.0 system to provide real-time help on component questions.<br />
|-<br />
|-<br />
|width="150"|Preferences||Released||Allows users to predefine a few basic visual settings and choose a Text Editor.<br />
|-<br />
|-<br />
|width="150"|Version Information||Released||Provides basic information about the currently installed user version of geWorkbench.<br />
|-<br />
|-<br />
|width="150"|Welcome Screen||Released||Introduction to geWorkbench during the initial opening of the application.<br />
|-<br />
|-<br />
|}<br />
<br />
<br />
==Network Generation==<br />
<br />
{|style="border: 1px solid lightGray"<br />
!Plugin||Status||Description<br />
|-<br />
|-<br />
|width="150"|ARACNe||Released||The Algorithm for the Reconstruction of Accurate Cellular Networks analyses large amount of microarray data (typically 100-500 microarrays) to reverse engineer underlying gene regulatory networks. ([[media:T_ARACNE_result1.png|Screenshot]])<br />
|-<br />
|-<br />
|width="150"|Cancer GEMS||Development||Interface to the NCI Cancer Genetic Markers of Susceptibility project.<br />
|-<br />
|-<br />
|width="150"|CNKB||Released||The Cellular Networks Knowledge Base queries an in-house repository of locally generated B-cell interaction network data and information from external databases in order to build a network of interactions for selected genes. ([[media:T_CNKB_ProtDNA_confidence75.png|Screenshot Throttle Graph]], [[media:T_CNKB_10at75_Cytoscape.png|Screenshot Network]])<br />
|-<br />
|-<br />
|width="150"|Cytoscape||Released||Visualization of gene regulatory network created in Reverse Engineering using [http://www.cytoscape.org/ Cytoscape 1.0]. ([[media:T_ARACNE_result1.png|Screenshot]])<br />
|-<br />
|-<br />
|width="150"|MINDy||Released||The Modulator Inference by Network Dynamics algorithm extends ARACNe to include detecting the influence of modulators of transcription factor activity.<br />
|-<br />
|-<br />
|width="150"|NetBoost||Development||NetBoost is a network characterization algorithm.<br />
|-<br />
|}<br />
<br />
<br />
==Normalization==<br />
<br />
{|style="border: 1px solid lightGray"<br />
!Plugin||Status||Description<br />
|-<br />
|-<br />
|width="150"|Array-Based Centering||Released||Subtraction of the mean or median measurement of a microarray from every measurement in that microarray.<br />
|-<br />
|-<br />
|width="150"|Housekeeping Normalizer||Released|| Normalization of all measurements in a microarray through division by the average expression value of a (user defined) set of housekeeping genes.<br />
|-<br />
|-<br />
|width="150"|Log2 Normalizer||Released||Applies a log2 transformation to all measurements in a microarray.<br />
|-<br />
|-<br />
|width="150"|Marker-Based Centering||Released||Subtraction of the mean or median measurement of a marker profile from every measurement in the profile.<br />
|-<br />
|-<br />
|width="150"|Mean-Variance Normalizer||Released||Transformation of expression measurements to standard units: for every marker, the mean measurement of the marker profile (across all microarrays in an experiment) is subtracted from each measurement in the profile and the resulting value is divided by the standard deviation of the profile.<br />
|-<br />
|-<br />
|width="150"|Missing Value Normalizer||Released||Replacement of missing values with consensus values.<br />
|-<br />
|-<br />
|width="150"|Quantile Normalizer||Released|| Expression measurements in each microarray are adjusted so that the distribution of values is the same across all microarrays in an experiment.<br />
|-<br />
|-<br />
|width="150"|Threshold Normalizer||Released||Adjustment of values that fall outside a user-specified threshold.<br />
|-<br />
|-<br />
|}<br />
<br />
<br />
== Sequence Analysis & Visualization ==<br />
<br />
{|style="border: 1px solid lightGray"<br />
!Plugin||Status||Description<br />
|-<br />
|-<br />
|width="150"|Alignment Results||Released||It parses and displays the results of sequence similarity searches which were run on the NCBI BLAST service. ([[media:T_SequenceAlignment_BLAST_results.png|Screenshot]])<br />
|-<br />
|-<br />
|width="150"|Pattern Discovery||Released|| Discovery of sequence motifs in sets of DNA and protein sequences. ([[media:T_PatternDiscovery_Params_Basic_histone_result_exact_seqs.png|Screenshot]])<br />
|-<br />
|-<br />
|width="150"|Position Histogram ||Released|| Visualization of results from the Pattern Discovery plugin. Motif/pattern support is plotted against relative sequence position of the motif match. ([[media:T_PatternDiscovery_Histones_Result_exact_Position_Histogram.png|Screenshot]])<br />
|-<br />
|-<br />
|width="150"|Promoter Analysis||Released||Identification of putative transcription factor binding sites in DNA sequences. The analysis use the profiles in the [http://jaspar.cgb.ki.se/cgi-bin/jaspar_db.pl JASPAR Transcription Factor Binding Profile Database]. ([[media:T_Promoter_CDH2_AP2_2000updn_setup_logo.png|Screenshot Logo]], [[media:T_Promoter_CDH2_AP2_2000updn_scan.png|Screenshot Sequence 1]], [[media:T_Promoter_CDH2_AP2_2000updn_scan_fullseq.png|Screenshot Sequence 2]])<br />
|-<br />
|-<br />
|width="150"|Sequence Alignment||Released||Run jobs on the NCBI BLAST servers directly within geWorkbench. <br />
|-<br />
|-<br />
|width="150"|Sequence Panel ||Released|| Visualization of results from the Pattern Discovery plugin, displaying the motif match location over each sequence from the input data set.<br />
|-<br />
|-<br />
|width="150"|Sequence Retriever||Released||Retrieve sequences for annotated markers from Santa Cruz (Nucleotides) and EBI (Proteins). ([[media:T_SequenceRetriever_AfterRetrieval.png|Screenshot]])<br />
|-<br />
|-<br />
|}<br />
<br />
<br />
==Visualization==<br />
<br />
{|style="border: 1px solid lightGray"<br />
!Plugin||Status||Description<br />
|-<br />
|-<br />
|width="150"|Analysis Panel||Released||Framework to support numerous, individually loadable analysis methods. <br />
|-<br />
|-<br />
|width="150"|ANOVA Tabular Viewer||Released||Displays the results of ANOVA analysis of gene expression data in tabular format. ([[media:T_ANOVA_Tabular_Viewer.png|Screenshot]])<br />
|-<br />
|-<br />
|width="150"|CEL Image Viewer||Released||Visualization of data in Affymetrix CEL files. ([[media:T_CEL_viewer.png|Screenshot]])<br />
|-<br />
|- <br />
|width="150"|Color Mosaic||Released||Heat maps for microarray expression data, organized by phenotypic or gene groupings. ([[media:GeWB_Color_Mosaic_Viewer.png|Screenshot]])<br />
|-<br />
|-<br />
|width="150"|Dendrogram||Released||Tree-structured diagrams reflecting the results of hierarchical clustering analysis. ([[media:T_HC_Dendrogram_display.png|Screenshot]])<br />
|-<br />
|-<br />
|width="150"|Evidence Integration Viewer||Development||Displays the results of the Evidence Integration analysis.<br />
|- <br />
|-<br />
|width="150"|Expression Profiles||Released||Line graph of genes expression profiles across several arrays/ hybridizations. ([[media:GeWB_Expression_Profile_2markers.png|Screenshot]])<br />
|- <br />
|-<br />
|width="150"|Expression Value Distribution||Released||Distribution plot of marker expression values across one or more microarrays. ([[media:T_EVD.png|Screenshot]])<br />
|-<br />
|-<br />
|width="150"|GeneWays||Released||An essential component needed to display elements in Cytoscape and ARACNe.<br />
|-<br />
|-<br />
|width="150"|GO Terms Viewer||Released||Displays the results of Gene Ontology Enrichment Analysis. ([[media:T_GO_Terms_TableBrowser_Gene_Detail.png|Screenshot]])<br />
|- <br />
|- <br />
|width="150"|Image Viewer||Released||Visualization of screenshots saved within geWorkbench (e.g. dendrograms).<br />
|- <br />
|- <br />
|width="150"|Jmol||Released|| Visualization of 3D protein structures from PDB files. ([[media:T_JMOL_Viewer.png|Screenshot]])<br />
|- <br />
|-<br />
|width="150"|Mark-Us Browser||Released|| Displays the results of a Mark-Us analysis. ([[media:T_MarkUs_Web_result.png|Screenshot]])<br />
|- <br />
|-<br />
|width="150"|MatrixReduce||Released||Visualization of MatrixReduce calculations using logo, chromosomal and tabular displays.<br />
|- <br />
|-<br />
|width="150"|MEDUSA Viewer||Development||Displays the results of a MEDUSA analysis.<br />
|- <br />
|-<br />
|width="150"|Microarray Viewer||Released||Color-gradient representation of gene expression values. ([[media:GeWB_Microarray_Viewer.png|Screenshot]])<br />
|- <br />
|-<br />
|width="150"|MINDy Viewer||Released||The results of a MINDy calculation are presented in several different tabular displays and a heat map.<br />
|- <br />
|-<br />
|width="150"|MRA Viewer||Released||Displays the results of the MRA in tablular and graphical form. ([[media:MRA_viewer_full.png|Screenshot]])<br />
|- <br />
|-<br />
|width="150"|NetBoost Viewer||Development||Displays a Boosting Iteration Graph, Confusion Matrix and Score Table from NetBoost Analysis.<br />
|- <br />
<br />
|-<br />
|width="150"|Normalization Panel||Released||Framework to support numerous, individually loadable normalization components.<br />
|-<br />
|-<br />
|width="150"|PCA Viewer||Released||Displays PCA results.<br />
|-<br />
|-<br />
|width="150"|Pudge Browser||Released||Visualization of Pudge results. ([[media:T_Pudge_Parameters.png|Screenshot Parameters]], [[media:T_Pudge_Alignment_example.png|Screenshot Result]])<br />
|- <br />
|-<br />
|width="150"|Scatter Plot||Released||Pairwise (array vs. array and marker vs. marker) comparison and plotting of expression values. ([[media:GeWB_Scatter_Plot_array_vs_array.png|Screenshot Array]], [[media:GeWB_Scatter_Plot_marker_vs_marker.png|Screenshot Marker]])<br />
|- <br />
|-<br />
|width="150"|SkyBase Viewer||Development||Displays the results from the SkyBase search.<br />
|- <br />
|-<br />
|width="150"|SkyLine Output All||Development||Displays all models from the Skyline modeling.<br />
|- <br />
|-<br />
|width="150"|SkyLine Output Each||Development||Displays each model from the Skyline modeling.<br />
|- <br />
|-<br />
|width="150"|SkyLine Contour||Development||A 2D dominance-based visualization of query results.<br />
|- <br />
|-<br />
|width="150"|SOM Clusters Viewer||Released||Visualization of gene clusters produced by the self-organizing maps analysis. ([[media:T_SOM_result.png|Screenshot]]) <br />
|-<br />
|-<br />
|width="150"|SVM Viewer||Released||Visualizes results obtained from classifying samples based on SVMs generated using the Gene Pattern v3 SVM service. <br />
|- <br />
|-<br />
|width="150"|Tabular Microarray Viewer||Released||Spreadsheet view of all expression measurement in an experiment, one row per individual marker/probe and one column per microarray. ([[media:GeWB_Tabular_Microarray_Viewer.png|Screenshot]])<br />
|-<br />
|-<br />
|width="150"| Volcano Plot||Released|| Visualize fold-change vs significance (P-value) for t-test results. ([[media:T_t-test_volcano_BCELL_webm_qldm.png|Screenshot]])<br />
|- <br />
|-<br />
|}</div>Zjihttp://wiki.c2b2.columbia.edu/workbench/index.php?title=Tutorial_-_Getting_Started&diff=6311Tutorial - Getting Started2010-06-10T21:34:08Z<p>Zji: /* Java: */</p>
<hr />
<div>{{TutorialsTopNav}}<br />
<br />
==Versions available:==<br />
[[Download | Downloads]] are available for current versions of Windows, Linux and Macintosh OS-X. Our primary development and testing platform is Windows XP.<br />
<br />
<br />
==Requirements:==<br />
<br />
===Java:===<br />
geWorkbench requires that a version of the Sun Java Runtime Environment 6.0 or higher be installed on your computer. (This is also known as JRE version 1.6). The JRE is available at [http://java.sun.com/javase/downloads/index.jsp java.sun.com]. However, the Windows and Linux versions of geWorkbench include the JRE in their download package, and the Macintosh supplies its own copy of the JRE.<br />
<br />
===Memory:===<br />
Testing of geWorkbench is done on machines with at least 1 GB of memory. Working with large datasets (100s of arrays) may require additional memory.<br />
<br />
==Installation:==<br />
<br />
See the [[Download | Download]] menu at left to obtain geWorkbench. The self-installing file includes all currently available geWorkbench modules as well as several example data files.<br />
The download package is created using InstallAnywhere from ZeroG Software.</div>Zjihttp://wiki.c2b2.columbia.edu/workbench/index.php?title=Collaborative_Development&diff=6127Collaborative Development2010-04-26T01:50:13Z<p>Zji: </p>
<hr />
<div>{{DevelopersTopNav}}<br />
<br />
We encourage developers of geWorkbench plugins to use our code repository. Our source code tree comprises 2 separate modules under ''geworkbench'', ''src'' for the core and ''components'' for the plugin code portions as outlined in the "[[Developers]]" section. <br />
<br />
Collaborative development typically takes place under the components module. The module contains a number of subdirectories, each corresponding to one geWorkbench component package, which can contain one of more related component plugins. Each subdirectory has the same basic structure:<br />
* A '''src''' directory containing the plugin code.<br />
* An optional '''lib''' directory containing jar files required by the plugin.<br />
<br />
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 directory. <br />
<br />
A full development environment can be then obtained by checking out the the project "geWorkbench" and one project for each subdirectory under "components". In this development space the plugin development team will be able to change the code of their plugin as they please after checking out the code. To commit new code into our code base hosted by NCI's subversion server, you need an NCICB account. Please contact us for more detail.</div>Zjihttp://wiki.c2b2.columbia.edu/workbench/index.php?title=Developers&diff=6126Developers2010-04-26T00:03:32Z<p>Zji: </p>
<hr />
<div>{{DevelopersTopNav}}<br />
<br />
geWorkbench is an open source Java-based platform and contributions by members of the community are welcome and encouraged. The latest code under development can be found at NCI's subversion server, https://ncisvn.nci.nih.gov/svn/geworkbench/. Anonymous read access is supported for all the code.<br />
<br />
<br />
Development in geWorkbench takes place along 2 parallel axes:<br />
* <u>'''geWorkbench core'''</u>: this portion of the code includes mainly 7 groups of packages:<br />
# ''engine'', which implements services related to the geWorkbench component architecture framework (e.g., plugin instantiation and visual layout, message delivery, component registry management, etc)<br />
# ''bison'' ('''B'''iomedical '''I'''nformatics '''S'''tructured '''ON'''tology) which contains the definition of the bioinformatics data types which form the basis of communication between the geWorkbench plugins.<br />
# ''analysis'', providing abstract for various analyses and processing<br />
# ''builtin'', supporting the internal execution and coordination of the core process, especially the project panel<br />
# ''components'', parsers and supports for input data format<br />
# ''events'', event classes used by communication between all components and the core<br />
# ''util'', all the utility libraries<br />
* <u>'''geWorkbench plugins'''</u>: this portion of the source tree contains the code for the various application plugin components (sample code for creating a simple plugin can be found [[A_Simple_Plugin |here]])<br />
<br />
There are no restrictions on who can develop a new component for geWorkbench. You can work against the development version or a release version of the geWorkbench core. To contribute your component to geWorkbench code, you need write access to the subversion server. Please contact us for the procedure.<br />
Contributions to the geWorkbench core packages are more controlled in order to avoid changes that may adversely affect large numbers of plugins.</div>Zjihttp://wiki.c2b2.columbia.edu/workbench/index.php?title=Software_Development_Kit&diff=6125Software Development Kit2010-04-25T23:49:51Z<p>Zji: /* An Example Plugin (geworkbench 1.7) */</p>
<hr />
<div>{{DevelopersTopNav}}<br />
<br />
The Development Kit is a self-contained package that facilitates the process of developing plugins for geWorkbench. <br />
<br />
== Using the Development Kit ==<br />
<br />
The Development Kit is available as a .zip file (see [[Download]] page). Unzip this archive, then follow the instructions below to create a geWorkbench plugin. Prerequisites to using the SDK are installing [http://ant.apache.org/manual/index.html ANT] and a [[Download#Software_Requirements|supported version]] of Java.<br />
<br />
The high-level steps for creating, testing and releasing a plugin are as follows:<br />
<br />
# From the command line, ''cd'' into the directory created after unpacking the archive.<br />
# Edit the provided Apache Ant build script to specify the name of your plugin.<br />
# Add the .java source files for your plugin to the <tt>src</tt> directory.<br />
# Add any .jar libraries that your plugin requires to the <tt>lib</tt> directory.<br />
# Run <tt>ant</tt> to build your plugin.<br />
# Edit the geWorkbench configuration file to add a directive for your new plugin.<br />
# Run geWorkbench with <tt>ant run</tt> to test your plugin.<br />
# Once satisfied with your plugin, use the provided utility to package your plugin in to a single file for distribution.<br />
<br />
The next section will illustrate the above steps with an example.<br />
<br />
== An Example Plugin (geworkbench 1.7 or later) ==<br />
<br />
We will create an example plugin that is simply called <tt>test</tt>. This will be a very simple visualization plugin that just displays a blank blue region.<br />
<br />
=== Setting the Plugin Name ===<br />
<br />
In the provided <tt>build.xml</tt>, change this line:<br />
<br />
<property name="component" value="noname"/><br />
<br />
to:<br />
<br />
<property name="component" value="test"/><br />
<br />
This specifies the name of our component, which is used for all build products.<br />
<br />
=== Adding Source ===<br />
<br />
Next, create and add a single .java source file to the org.organization.test package. To do this, first, create the file <tt>TestComponent.java</tt> (in your favorite editor) and copy and paste the code below in this file. Then, create the directories <tt>src/org/organization/test</tt> in /src and place <tt>TestComponent.java</tt> file in this directory.<br />
<br />
package org.organization.test;<br />
<br />
import org.geworkbench.engine.config.VisualPlugin;<br />
<br />
import javax.swing.*;<br />
import java.awt.*;<br />
<br />
/**<br />
* A simple demonstration component.<br />
*/<br />
public class TestComponent implements VisualPlugin {<br />
<br />
private JPanel panel;<br />
<br />
public TestComponent() {<br />
panel = new JPanel();<br />
panel.setBackground(Color.blue);<br />
}<br />
<br />
public Component getComponent() {<br />
return panel;<br />
}<br />
}<br />
<br />
If the component requires any .jar files, add them to the <tt>lib</tt> directory.<br />
<br />
=== Configure Plugin ===<br />
<br />
Create a .cwb.xml file for your plugin and place it under the same directory as the source file. In this case, create ''test.cwb.xml'' and place it under ''GEWORKBENCHSDK_HOME/src/org/organization/test''.<br />
<br />
<component-descriptor xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="ConfigurationFile Schema.xsd"><br />
<component name="Test SDK Panel" <br />
class="org.organization.test.TestComponent" <br />
version="1.0"<br />
author="C2B2"<br />
authorURL=""<br />
toolURL=""<br />
description="test SDK"<br />
visualizer="true"><br />
<license><br />
<![CDATA[<br />
<html><head><meta http-equiv=Content-Type content="text/html; charset=windows-1252"></head><br />
<body>----</body><br />
</html><br />
]]></license><br />
</component><br />
<plugin id="TestSDKPanel" name="Test SDK" class="org.organization.test.TestComponent" source="test"><br />
<gui-area name="VisualArea"/><br />
</plugin><br />
</component-descriptor><br />
<br />
=== Running the Plugin in geWorkbench ===<br />
<br />
To run the plugin and see it appear in geWorkbench (a blue visual), do the following:<br />
<br />
ant run<br />
<br />
When geWorkbench appears, right click on the ''Workspace'' and select ''New Project''. You should see the blue visual plugin.<br />
<br />
=== Releasing the Plugin ===<br />
<br />
To create a plugin release, type:<br />
<br />
ant gear<br />
<br />
This creates the file <tt>test.gear</tt>. This gear file is a bundled plugin that can deployed to a geWorkbench installation by placing the file in the <tt>components</tt> directory, then unzipping it.<br />
<br />
== An Example Plugin (Pre geworkbench 1.7) ==<br />
<br />
We will create an example plugin that is simply called <tt>test</tt>. This will be a very simple visualization plugin that just displays a blank blue region.<br />
<br />
=== Setting the Plugin Name ===<br />
<br />
In the provided <tt>build.xml</tt>, change this line:<br />
<br />
<property name="component" value="noname"/><br />
<br />
to:<br />
<br />
<property name="component" value="test"/><br />
<br />
This specifies the name of our component, which is used for all build products.<br />
<br />
=== Adding Source ===<br />
<br />
Next, create and add a single .java source file to the org.organization.test package. To do this, first, create the file <tt>TestComponent.java</tt> (in your favorite editor) and copy and paste the code below in this file. Then, create the directories <tt>src/org/organization/test</tt> in /src and place <tt>TestComponent.java</tt> file in this directory.<br />
<br />
package org.organization.test;<br />
<br />
import org.geworkbench.engine.config.VisualPlugin;<br />
<br />
import javax.swing.*;<br />
import java.awt.*;<br />
<br />
/**<br />
* A simple demonstration component.<br />
*/<br />
public class TestComponent implements VisualPlugin {<br />
<br />
private JPanel panel;<br />
<br />
public TestComponent() {<br />
panel = new JPanel();<br />
panel.setBackground(Color.blue);<br />
}<br />
<br />
public Component getComponent() {<br />
return panel;<br />
}<br />
}<br />
<br />
If the component requires any .jar files, add them to the <tt>lib</tt> directory.<br />
<br />
=== Configure Plugin ===<br />
<br />
The configuration file for the Development Kit is called <tt>minimal.xml</tt> and it is in the <tt>conf</tt> directory. <br />
<br />
Add the following to the bottom of <tt>minimal.xml</tt> (before ''</geaw-config>''):<br />
<br />
<plugin id="testPanel" name="Test Panel" class="org.organization.test.TestComponent" source="test"><br />
<gui-area name="VisualArea"/><br />
</plugin><br />
<br />
=== Running the Plugin in geWorkbench ===<br />
<br />
To run the plugn and see it appear in geWorkbench (a blue visual), do the following:<br />
<br />
ant run<br />
<br />
When geWorkbench appears, right click on the ''Workspace'' and select ''New Project''. You should see the blue visual plugin.<br />
<br />
=== Releasing the Plugin ===<br />
<br />
To create a plugin release, type:<br />
<br />
ant gear<br />
<br />
This creates the file <tt>test.gear</tt>. A .gear file is the geWorkbench analogue of a .war file for a web application. Is a bundled plugin that can deployed to a geWorkbench install by placing the file in the <tt>components</tt> directory. A configuration directive (such as the one above) would also need to be added to the configuration file to activate the plugin.</div>Zjihttp://wiki.c2b2.columbia.edu/workbench/index.php?title=Software_Development_Kit&diff=6124Software Development Kit2010-04-25T23:49:15Z<p>Zji: /* Configure Plugin */</p>
<hr />
<div>{{DevelopersTopNav}}<br />
<br />
The Development Kit is a self-contained package that facilitates the process of developing plugins for geWorkbench. <br />
<br />
== Using the Development Kit ==<br />
<br />
The Development Kit is available as a .zip file (see [[Download]] page). Unzip this archive, then follow the instructions below to create a geWorkbench plugin. Prerequisites to using the SDK are installing [http://ant.apache.org/manual/index.html ANT] and a [[Download#Software_Requirements|supported version]] of Java.<br />
<br />
The high-level steps for creating, testing and releasing a plugin are as follows:<br />
<br />
# From the command line, ''cd'' into the directory created after unpacking the archive.<br />
# Edit the provided Apache Ant build script to specify the name of your plugin.<br />
# Add the .java source files for your plugin to the <tt>src</tt> directory.<br />
# Add any .jar libraries that your plugin requires to the <tt>lib</tt> directory.<br />
# Run <tt>ant</tt> to build your plugin.<br />
# Edit the geWorkbench configuration file to add a directive for your new plugin.<br />
# Run geWorkbench with <tt>ant run</tt> to test your plugin.<br />
# Once satisfied with your plugin, use the provided utility to package your plugin in to a single file for distribution.<br />
<br />
The next section will illustrate the above steps with an example.<br />
<br />
== An Example Plugin (geworkbench 1.7) ==<br />
<br />
We will create an example plugin that is simply called <tt>test</tt>. This will be a very simple visualization plugin that just displays a blank blue region.<br />
<br />
=== Setting the Plugin Name ===<br />
<br />
In the provided <tt>build.xml</tt>, change this line:<br />
<br />
<property name="component" value="noname"/><br />
<br />
to:<br />
<br />
<property name="component" value="test"/><br />
<br />
This specifies the name of our component, which is used for all build products.<br />
<br />
=== Adding Source ===<br />
<br />
Next, create and add a single .java source file to the org.organization.test package. To do this, first, create the file <tt>TestComponent.java</tt> (in your favorite editor) and copy and paste the code below in this file. Then, create the directories <tt>src/org/organization/test</tt> in /src and place <tt>TestComponent.java</tt> file in this directory.<br />
<br />
package org.organization.test;<br />
<br />
import org.geworkbench.engine.config.VisualPlugin;<br />
<br />
import javax.swing.*;<br />
import java.awt.*;<br />
<br />
/**<br />
* A simple demonstration component.<br />
*/<br />
public class TestComponent implements VisualPlugin {<br />
<br />
private JPanel panel;<br />
<br />
public TestComponent() {<br />
panel = new JPanel();<br />
panel.setBackground(Color.blue);<br />
}<br />
<br />
public Component getComponent() {<br />
return panel;<br />
}<br />
}<br />
<br />
If the component requires any .jar files, add them to the <tt>lib</tt> directory.<br />
<br />
=== Configure Plugin ===<br />
<br />
Create a .cwb.xml file for your plugin and place it under the same directory as the source file. In this case, create ''test.cwb.xml'' and place it under ''GEWORKBENCHSDK_HOME/src/org/organization/test''.<br />
<br />
<component-descriptor xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="ConfigurationFile Schema.xsd"><br />
<component name="Test SDK Panel" <br />
class="org.organization.test.TestComponent" <br />
version="1.0"<br />
author="C2B2"<br />
authorURL=""<br />
toolURL=""<br />
description="test SDK"<br />
visualizer="true"><br />
<license><br />
<![CDATA[<br />
<html><head><meta http-equiv=Content-Type content="text/html; charset=windows-1252"></head><br />
<body>----</body><br />
</html><br />
]]></license><br />
</component><br />
<plugin id="TestSDKPanel" name="Test SDK" class="org.organization.test.TestComponent" source="test"><br />
<gui-area name="VisualArea"/><br />
</plugin><br />
</component-descriptor><br />
<br />
=== Running the Plugin in geWorkbench ===<br />
<br />
To run the plugin and see it appear in geWorkbench (a blue visual), do the following:<br />
<br />
ant run<br />
<br />
When geWorkbench appears, right click on the ''Workspace'' and select ''New Project''. You should see the blue visual plugin.<br />
<br />
=== Releasing the Plugin ===<br />
<br />
To create a plugin release, type:<br />
<br />
ant gear<br />
<br />
This creates the file <tt>test.gear</tt>. This gear file is a bundled plugin that can deployed to a geWorkbench installation by placing the file in the <tt>components</tt> directory, then unzipping it.<br />
<br />
== An Example Plugin (Pre geworkbench 1.7) ==<br />
<br />
We will create an example plugin that is simply called <tt>test</tt>. This will be a very simple visualization plugin that just displays a blank blue region.<br />
<br />
=== Setting the Plugin Name ===<br />
<br />
In the provided <tt>build.xml</tt>, change this line:<br />
<br />
<property name="component" value="noname"/><br />
<br />
to:<br />
<br />
<property name="component" value="test"/><br />
<br />
This specifies the name of our component, which is used for all build products.<br />
<br />
=== Adding Source ===<br />
<br />
Next, create and add a single .java source file to the org.organization.test package. To do this, first, create the file <tt>TestComponent.java</tt> (in your favorite editor) and copy and paste the code below in this file. Then, create the directories <tt>src/org/organization/test</tt> in /src and place <tt>TestComponent.java</tt> file in this directory.<br />
<br />
package org.organization.test;<br />
<br />
import org.geworkbench.engine.config.VisualPlugin;<br />
<br />
import javax.swing.*;<br />
import java.awt.*;<br />
<br />
/**<br />
* A simple demonstration component.<br />
*/<br />
public class TestComponent implements VisualPlugin {<br />
<br />
private JPanel panel;<br />
<br />
public TestComponent() {<br />
panel = new JPanel();<br />
panel.setBackground(Color.blue);<br />
}<br />
<br />
public Component getComponent() {<br />
return panel;<br />
}<br />
}<br />
<br />
If the component requires any .jar files, add them to the <tt>lib</tt> directory.<br />
<br />
=== Configure Plugin ===<br />
<br />
The configuration file for the Development Kit is called <tt>minimal.xml</tt> and it is in the <tt>conf</tt> directory. <br />
<br />
Add the following to the bottom of <tt>minimal.xml</tt> (before ''</geaw-config>''):<br />
<br />
<plugin id="testPanel" name="Test Panel" class="org.organization.test.TestComponent" source="test"><br />
<gui-area name="VisualArea"/><br />
</plugin><br />
<br />
=== Running the Plugin in geWorkbench ===<br />
<br />
To run the plugn and see it appear in geWorkbench (a blue visual), do the following:<br />
<br />
ant run<br />
<br />
When geWorkbench appears, right click on the ''Workspace'' and select ''New Project''. You should see the blue visual plugin.<br />
<br />
=== Releasing the Plugin ===<br />
<br />
To create a plugin release, type:<br />
<br />
ant gear<br />
<br />
This creates the file <tt>test.gear</tt>. A .gear file is the geWorkbench analogue of a .war file for a web application. Is a bundled plugin that can deployed to a geWorkbench install by placing the file in the <tt>components</tt> directory. A configuration directive (such as the one above) would also need to be added to the configuration file to activate the plugin.</div>Zjihttp://wiki.c2b2.columbia.edu/workbench/index.php?title=A_Simple_Plugin&diff=6123A Simple Plugin2010-04-25T23:47:32Z<p>Zji: /* Configuration */</p>
<hr />
<div>{{DevelopersTopNav}}<br />
<br />
This introduction introduces the basic concepts for geWorkbench developers. It also walks through the creation of a simple component.<br />
<br />
== Introduction ==<br />
<br />
geWorkbench is a component-based application framework. All functionality of the software is provided by components which can be added, removed and configured in a flexible way. All the visual plugins, analysis tools and even file filters are implemented as components.<br />
<br />
== Application Layout ==<br />
<br />
The application framework allows for a pluggable "skin" that controls how components are displayed to the user. The details of plugging in a new skin are out of the scope of this document. Here, the focus will be on the default skin.<br />
<br />
There are four main ''areas'' in geWorkbench:<br />
<br />
[[Image:VisualAreas.png]]<br />
<br />
=== Project Area ===<br />
<br />
[[Image:ProjectArea.png]]<br />
<br />
This area contains the ''Project Panel''. This is where data files are loaded and the results of analyses are made available. It is the primary way the user interacts with the software. Selecting a data set in the Project Panel affects what is visible in the other areas of the application.<br />
<br />
=== Selection Area ===<br />
<br />
[[Image:SelectionArea.png]]<br />
<br />
This area contains the components that allow the searching and selection of data set elements. For example, microarray sets have phenotype and gene (probe) selector panels.<br />
<br />
=== Visual Area ===<br />
<br />
[[Image:VisualArea.png]]<br />
<br />
This area contains visualization components for the data set currently selected. Large, self-contained components will also likely appear in this area.<br />
<br />
=== Command Area ===<br />
<br />
[[Image:CommandArea.png]]<br />
<br />
Analysis components and other miscellaneous components are found in the Command Area. Many of these anlyses result in the creation of ancillary data sets which appear in the Project Panel.<br />
<br />
== Component Model ==<br />
<br />
File filters, anlyses and visual plug-ins are all ''components'' in geWorkbench. This section will cover the basics of the component model by developing a simple example component.<br />
<br />
=== Example Component ===<br />
<br />
A simple visual component that operates on microarray sets will be developed. A ''microarray set'' is a set of related microarray experiments, each operating on the same chip type and with the same probes. The example component will simply display the number of microarrays in the microarray set as well as the number of markers (probes).<br />
<br />
[[Image:ExampleComponent.gif]]<br />
<br />
=== The Source ===<br />
<br />
Here is the source for the example component in its entirety. The code will be examined in detail in the following sections.<br />
<br />
<pre><br />
@AcceptTypes({DSMicroarraySet.class})<br />
public class ExampleComponent extends JPanel implements VisualPlugin {<br />
<br />
private DSMicroarraySet microarraySet;<br />
private JLabel infoLabel;<br />
<br />
public ExampleComponent() {<br />
infoLabel = new JLabel("");<br />
add(infoLabel);<br />
}<br />
<br />
public Component getComponent() {<br />
// In this case, this object is also the GUI component.<br />
return this;<br />
}<br />
<br />
@Subscribe public void receive(ProjectEvent event, Object source) {<br />
DSDataSet dataSet = event.getDataSet();<br />
// We will act on this object if it is a DSMicroarraySet<br />
if (dataSet instanceof DSMicroarraySet) {<br />
microarraySet = (DSMicroarraySet) dataSet;<br />
// We just received a new microarray set, <br />
// so populate the info label with some basic stats.<br />
String htmlText = "<html><body>"<br />
+ "<h3>" + microarraySet.getLabel() + "</h3><br>"<br />
+ "<table>"<br />
+ "<tr><td>Arrays:</td><td><b>" + microarraySet.size() <br />
+ "</b></td></tr>"<br />
+ "<tr><td>Markers:</td><td><b>"<br />
+ microarraySet.getMarkers().size() <br />
+ "</b></td></tr>"<br />
+ "</table>"<br />
+ "</body></html>";<br />
infoLabel.setText(htmlText);<br />
}<br />
}<br />
}<br />
</pre><br />
<br />
=== Class Declaration ===<br />
<br />
<pre><br />
@AcceptTypes({DSMicroarraySet.class})<br />
public class ExampleComponent extends JPanel implements VisualPlugin {<br />
</pre><br />
<br />
The class declaration is prefixed with a Java 1.5 annotation called <code>AcceptTypes</code>. This annotation indicates what data sets on which this plugin will operate. It takes an array of <code>java.lang.Class</code> parameters. Each class specified must be assignable to <code>DSDataSet</code>, the root class of all data sets. Leaving the annotation out completely will result in the component to be present in the interface at all times.<br />
<br />
The declaration itself indicates that the components implements <code>VisualPlugin</code>. This interface specifies that the component is visual. Non-visual components such as file filters and analyses do not implement this interface.<br />
<br />
=== Fields and Constructor ===<br />
<br />
<pre><br />
private DSMicroarraySet microarraySet;<br />
private JLabel infoLabel;<br />
<br />
public ExampleComponent() {<br />
infoLabel = new JLabel("");<br />
add(infoLabel);<br />
}<br />
</pre><br />
<br />
A no-arg constructor is required, as the component will be instantiated by the application engine.<br />
<br />
=== VisualPlugin ===<br />
<br />
<pre><br />
public Component getComponent() {<br />
// In this case, this object is also the GUI component.<br />
return this;<br />
}<br />
</pre><br />
<br />
This method is the realization of the <code>VisualPlugin</code> interface. The application engine calls this to acquire the <code>java.awt.Component</code>. In this case, the component itself is a <code>JPanel</code>, so it is simply returned. This method should always return the same object for the lifecycle of the instance.<br />
<br />
=== @Subscribe Methods ===<br />
<br />
<pre><br />
@Subscribe public void receive(ProjectEvent event, Object source) {<br />
...<br />
}<br />
</pre><br />
<br />
Methods annotated with <code>@Subscribe</code> are called by geWorkbench when an object of the appropriate type is published. In this case, the method will be called by the engine when another component publishes an object of type <code>ProjectEvent</code>. The second parameter to the method is the publishing compoent itself, although this should rarely be needed. A method annotated with <code>@Subscribe</code> that does not take exactly two parameters will cause an error.<br />
<br />
The <code>ProjectEvent</code> is published by the Project Panel. It is published upon the selection of a data set. Almost all components will subscribe to this kind of event.<br />
<br />
A project event is handled by introspecting the data set and then acting upon it:<br />
<br />
<pre><br />
@Subscribe public void receive(ProjectEvent event, Object source) {<br />
DSDataSet dataSet = event.getDataSet();<br />
// We will act on this object if it is a DSMicroarraySet<br />
if (dataSet instanceof DSMicroarraySet) {<br />
microarraySet = (DSMicroarraySet) dataSet;<br />
...<br />
}<br />
}<br />
</pre><br />
<br />
In the above case, events for data sets other than <code>DSMicroarraySet</code> are ignored. A subscriber for project events should always check the type of received data sets regardless of what is specified in the <code>@AcceptTypes</code> annotation.<br />
<br />
=== The Details ===<br />
<br />
<pre><br />
@Subscribe public void receive(ProjectEvent event, Object source) {<br />
DSDataSet dataSet = event.getDataSet();<br />
// We will act on this object if it is a DSMicroarraySet<br />
if (dataSet instanceof DSMicroarraySet) {<br />
microarraySet = (DSMicroarraySet) dataSet;<br />
// We just received a new microarray set, <br />
// so populate the info label with some basic stats.<br />
String htmlText = "<html><body>"<br />
+ "<h3>" + microarraySet.getLabel() + "</h3><br>"<br />
+ "<table>"<br />
+ "<tr><td>Arrays:</td><td><b>" + microarraySet.size() <br />
+ "</b></td></tr>"<br />
+ "<tr><td>Markers:</td><td><b>"<br />
+ microarraySet.getMarkers().size() <br />
+ "</b></td></tr>"<br />
+ "</table>"<br />
+ "</body></html>";<br />
infoLabel.setText(htmlText);<br />
}<br />
}<br />
</pre><br />
<br />
In this code snippet, the number of arrays and markers are extracted and displayed in an HTML label. Note that this is rendered every time a microarray set is selected in the project panel.<br />
<br />
Again, the screenshot of the component at work:<br />
<br />
[[Image:ExampleComponent.gif]]<br />
<br />
== Component Resources ==<br />
<br />
Once one or more related components are written, they are combined in to ''component resources'' for deployment to geWorkbench. This is just a simple directory structure, similar to WAR files in web applications.<br />
<br />
[[Image:ResourceStructure.png]]<br />
<br />
A directory is created in the <tt>components</tt> subdirectory. In this case, it is called <tt>example</tt>. In this directory is a <tt>lib</tt> folder, which contains jar files that are needed by the component. Note that jar files that are required by the component but are already present in geWorkbench's main lib directory need not be included here, although it does no harm. Also in this directory is a <tt>classes</tt> directory, which contains the compiled classes for the component as well as any property or resource files required for the component to function.<br />
<br />
The geWorkbench engine will instantiate a new classloader for each component. This classloader will resolve classes as follows:<br />
<br />
# Component's <tt>classes</tt> directory.<br />
# Component's <tt>lib</tt> directory.<br />
# geWorkbench's classloader.<br />
<br />
Component resource files can also be packaged up in to ''GEAR'' files ('''ge'''Workbench '''Ar'''chive) for easy download and deployment. See the section on [[.GEAR files|GEAR files]] for more information.<br />
<br />
== Configuration ==<br />
<br />
Configuration of the application is controlled by XML files, including one configuration xml file and one xml file for each plugin component. The main xml file can be specified as a command-line argument to geWorkbench, or a default XML file will be chosen if none is specified. Each component's configuration file should be in the same directory of the java class and has the name matching the java class except for the extension .cwb.xml. The schema for the main configuration file and the components' configuration files are available. See <tt>geWorkbench/src/org/geworkbench/engine/config</tt> for some example configuration files.<br />
<br />
A typical configuration directive for the above exmaple component is as follows:<br />
<br />
<pre><br />
<plugin id="Example" name="Example" <br />
class="org.geworkbench.components.example.ExampleComponent" <br />
source="example"><br />
<gui-area name="VisualArea"/><br />
</plugin><br />
</pre><br />
<br />
* The <tt>id</tt> attribute is just a unique identifier for the component.<br />
* The <tt>name</tt> attribute is the name that appears in the interface (if visual).<br />
* The <tt>class</tt> attribute is the full class name of the component.<br />
* The <tt>source</tt> attribute is the resource directory where the component can be found.<br />
* The <tt>&lt;gui-area&gt;</tt> element is used to define how the component should be displayed. It is for visual components only. In this case, we put the component in to the main visual area of the application.</div>Zjihttp://wiki.c2b2.columbia.edu/workbench/index.php?title=A_Simple_Plugin&diff=6122A Simple Plugin2010-04-25T23:46:46Z<p>Zji: /* Configuration */</p>
<hr />
<div>{{DevelopersTopNav}}<br />
<br />
This introduction introduces the basic concepts for geWorkbench developers. It also walks through the creation of a simple component.<br />
<br />
== Introduction ==<br />
<br />
geWorkbench is a component-based application framework. All functionality of the software is provided by components which can be added, removed and configured in a flexible way. All the visual plugins, analysis tools and even file filters are implemented as components.<br />
<br />
== Application Layout ==<br />
<br />
The application framework allows for a pluggable "skin" that controls how components are displayed to the user. The details of plugging in a new skin are out of the scope of this document. Here, the focus will be on the default skin.<br />
<br />
There are four main ''areas'' in geWorkbench:<br />
<br />
[[Image:VisualAreas.png]]<br />
<br />
=== Project Area ===<br />
<br />
[[Image:ProjectArea.png]]<br />
<br />
This area contains the ''Project Panel''. This is where data files are loaded and the results of analyses are made available. It is the primary way the user interacts with the software. Selecting a data set in the Project Panel affects what is visible in the other areas of the application.<br />
<br />
=== Selection Area ===<br />
<br />
[[Image:SelectionArea.png]]<br />
<br />
This area contains the components that allow the searching and selection of data set elements. For example, microarray sets have phenotype and gene (probe) selector panels.<br />
<br />
=== Visual Area ===<br />
<br />
[[Image:VisualArea.png]]<br />
<br />
This area contains visualization components for the data set currently selected. Large, self-contained components will also likely appear in this area.<br />
<br />
=== Command Area ===<br />
<br />
[[Image:CommandArea.png]]<br />
<br />
Analysis components and other miscellaneous components are found in the Command Area. Many of these anlyses result in the creation of ancillary data sets which appear in the Project Panel.<br />
<br />
== Component Model ==<br />
<br />
File filters, anlyses and visual plug-ins are all ''components'' in geWorkbench. This section will cover the basics of the component model by developing a simple example component.<br />
<br />
=== Example Component ===<br />
<br />
A simple visual component that operates on microarray sets will be developed. A ''microarray set'' is a set of related microarray experiments, each operating on the same chip type and with the same probes. The example component will simply display the number of microarrays in the microarray set as well as the number of markers (probes).<br />
<br />
[[Image:ExampleComponent.gif]]<br />
<br />
=== The Source ===<br />
<br />
Here is the source for the example component in its entirety. The code will be examined in detail in the following sections.<br />
<br />
<pre><br />
@AcceptTypes({DSMicroarraySet.class})<br />
public class ExampleComponent extends JPanel implements VisualPlugin {<br />
<br />
private DSMicroarraySet microarraySet;<br />
private JLabel infoLabel;<br />
<br />
public ExampleComponent() {<br />
infoLabel = new JLabel("");<br />
add(infoLabel);<br />
}<br />
<br />
public Component getComponent() {<br />
// In this case, this object is also the GUI component.<br />
return this;<br />
}<br />
<br />
@Subscribe public void receive(ProjectEvent event, Object source) {<br />
DSDataSet dataSet = event.getDataSet();<br />
// We will act on this object if it is a DSMicroarraySet<br />
if (dataSet instanceof DSMicroarraySet) {<br />
microarraySet = (DSMicroarraySet) dataSet;<br />
// We just received a new microarray set, <br />
// so populate the info label with some basic stats.<br />
String htmlText = "<html><body>"<br />
+ "<h3>" + microarraySet.getLabel() + "</h3><br>"<br />
+ "<table>"<br />
+ "<tr><td>Arrays:</td><td><b>" + microarraySet.size() <br />
+ "</b></td></tr>"<br />
+ "<tr><td>Markers:</td><td><b>"<br />
+ microarraySet.getMarkers().size() <br />
+ "</b></td></tr>"<br />
+ "</table>"<br />
+ "</body></html>";<br />
infoLabel.setText(htmlText);<br />
}<br />
}<br />
}<br />
</pre><br />
<br />
=== Class Declaration ===<br />
<br />
<pre><br />
@AcceptTypes({DSMicroarraySet.class})<br />
public class ExampleComponent extends JPanel implements VisualPlugin {<br />
</pre><br />
<br />
The class declaration is prefixed with a Java 1.5 annotation called <code>AcceptTypes</code>. This annotation indicates what data sets on which this plugin will operate. It takes an array of <code>java.lang.Class</code> parameters. Each class specified must be assignable to <code>DSDataSet</code>, the root class of all data sets. Leaving the annotation out completely will result in the component to be present in the interface at all times.<br />
<br />
The declaration itself indicates that the components implements <code>VisualPlugin</code>. This interface specifies that the component is visual. Non-visual components such as file filters and analyses do not implement this interface.<br />
<br />
=== Fields and Constructor ===<br />
<br />
<pre><br />
private DSMicroarraySet microarraySet;<br />
private JLabel infoLabel;<br />
<br />
public ExampleComponent() {<br />
infoLabel = new JLabel("");<br />
add(infoLabel);<br />
}<br />
</pre><br />
<br />
A no-arg constructor is required, as the component will be instantiated by the application engine.<br />
<br />
=== VisualPlugin ===<br />
<br />
<pre><br />
public Component getComponent() {<br />
// In this case, this object is also the GUI component.<br />
return this;<br />
}<br />
</pre><br />
<br />
This method is the realization of the <code>VisualPlugin</code> interface. The application engine calls this to acquire the <code>java.awt.Component</code>. In this case, the component itself is a <code>JPanel</code>, so it is simply returned. This method should always return the same object for the lifecycle of the instance.<br />
<br />
=== @Subscribe Methods ===<br />
<br />
<pre><br />
@Subscribe public void receive(ProjectEvent event, Object source) {<br />
...<br />
}<br />
</pre><br />
<br />
Methods annotated with <code>@Subscribe</code> are called by geWorkbench when an object of the appropriate type is published. In this case, the method will be called by the engine when another component publishes an object of type <code>ProjectEvent</code>. The second parameter to the method is the publishing compoent itself, although this should rarely be needed. A method annotated with <code>@Subscribe</code> that does not take exactly two parameters will cause an error.<br />
<br />
The <code>ProjectEvent</code> is published by the Project Panel. It is published upon the selection of a data set. Almost all components will subscribe to this kind of event.<br />
<br />
A project event is handled by introspecting the data set and then acting upon it:<br />
<br />
<pre><br />
@Subscribe public void receive(ProjectEvent event, Object source) {<br />
DSDataSet dataSet = event.getDataSet();<br />
// We will act on this object if it is a DSMicroarraySet<br />
if (dataSet instanceof DSMicroarraySet) {<br />
microarraySet = (DSMicroarraySet) dataSet;<br />
...<br />
}<br />
}<br />
</pre><br />
<br />
In the above case, events for data sets other than <code>DSMicroarraySet</code> are ignored. A subscriber for project events should always check the type of received data sets regardless of what is specified in the <code>@AcceptTypes</code> annotation.<br />
<br />
=== The Details ===<br />
<br />
<pre><br />
@Subscribe public void receive(ProjectEvent event, Object source) {<br />
DSDataSet dataSet = event.getDataSet();<br />
// We will act on this object if it is a DSMicroarraySet<br />
if (dataSet instanceof DSMicroarraySet) {<br />
microarraySet = (DSMicroarraySet) dataSet;<br />
// We just received a new microarray set, <br />
// so populate the info label with some basic stats.<br />
String htmlText = "<html><body>"<br />
+ "<h3>" + microarraySet.getLabel() + "</h3><br>"<br />
+ "<table>"<br />
+ "<tr><td>Arrays:</td><td><b>" + microarraySet.size() <br />
+ "</b></td></tr>"<br />
+ "<tr><td>Markers:</td><td><b>"<br />
+ microarraySet.getMarkers().size() <br />
+ "</b></td></tr>"<br />
+ "</table>"<br />
+ "</body></html>";<br />
infoLabel.setText(htmlText);<br />
}<br />
}<br />
</pre><br />
<br />
In this code snippet, the number of arrays and markers are extracted and displayed in an HTML label. Note that this is rendered every time a microarray set is selected in the project panel.<br />
<br />
Again, the screenshot of the component at work:<br />
<br />
[[Image:ExampleComponent.gif]]<br />
<br />
== Component Resources ==<br />
<br />
Once one or more related components are written, they are combined in to ''component resources'' for deployment to geWorkbench. This is just a simple directory structure, similar to WAR files in web applications.<br />
<br />
[[Image:ResourceStructure.png]]<br />
<br />
A directory is created in the <tt>components</tt> subdirectory. In this case, it is called <tt>example</tt>. In this directory is a <tt>lib</tt> folder, which contains jar files that are needed by the component. Note that jar files that are required by the component but are already present in geWorkbench's main lib directory need not be included here, although it does no harm. Also in this directory is a <tt>classes</tt> directory, which contains the compiled classes for the component as well as any property or resource files required for the component to function.<br />
<br />
The geWorkbench engine will instantiate a new classloader for each component. This classloader will resolve classes as follows:<br />
<br />
# Component's <tt>classes</tt> directory.<br />
# Component's <tt>lib</tt> directory.<br />
# geWorkbench's classloader.<br />
<br />
Component resource files can also be packaged up in to ''GEAR'' files ('''ge'''Workbench '''Ar'''chive) for easy download and deployment. See the section on [[.GEAR files|GEAR files]] for more information.<br />
<br />
== Configuration ==<br />
<br />
Configuration of the application is controlled by XML files, including one configuration xml file and one xml file for each plugin component. The main xml file can be specified as a command-line argument to geWorkbench, or a default XML file will be chosen if none is specified. Each component's configuration file should be in the same directory of the java class and has the name matching the java class except for the extension .cwb.xml. The schema for the main configuration file and the components' configuration files are available. See <tt>geWorkbench/src/org/geworkbench/engine/config</tt> for some example configuration files.<br />
<br />
A typical configuration directive for the above exmaple component is as follows:<br />
<br />
<pre><br />
<plugin id="Example" name="Example" <br />
class="org.geworkbench.components.example.ExampleComponent" <br />
source="example"><br />
<gui-area name="VisualArea"/><br />
</plugin><br />
</pre><br />
<br />
* Components are made available to the application via the <tt>&lt;plugin&gt;</tt> element.<br />
* The <tt>id</tt> attribute is just a unique identifier for the component.<br />
* The <tt>name</tt> attribute is the name that appears in the interface (if visual).<br />
* The <tt>class</tt> attribute is the full class name of the component.<br />
* The <tt>source</tt> attribute is the resource directory where the component can be found.<br />
* The <tt>&lt;gui-area&gt;</tt> element is used to define how the component should be displayed. It is for visual components only. In this case, we put the component in to the main visual area of the application.</div>Zjihttp://wiki.c2b2.columbia.edu/workbench/index.php?title=A_Simple_Plugin&diff=6121A Simple Plugin2010-04-25T23:42:53Z<p>Zji: /* Configuration */</p>
<hr />
<div>{{DevelopersTopNav}}<br />
<br />
This introduction introduces the basic concepts for geWorkbench developers. It also walks through the creation of a simple component.<br />
<br />
== Introduction ==<br />
<br />
geWorkbench is a component-based application framework. All functionality of the software is provided by components which can be added, removed and configured in a flexible way. All the visual plugins, analysis tools and even file filters are implemented as components.<br />
<br />
== Application Layout ==<br />
<br />
The application framework allows for a pluggable "skin" that controls how components are displayed to the user. The details of plugging in a new skin are out of the scope of this document. Here, the focus will be on the default skin.<br />
<br />
There are four main ''areas'' in geWorkbench:<br />
<br />
[[Image:VisualAreas.png]]<br />
<br />
=== Project Area ===<br />
<br />
[[Image:ProjectArea.png]]<br />
<br />
This area contains the ''Project Panel''. This is where data files are loaded and the results of analyses are made available. It is the primary way the user interacts with the software. Selecting a data set in the Project Panel affects what is visible in the other areas of the application.<br />
<br />
=== Selection Area ===<br />
<br />
[[Image:SelectionArea.png]]<br />
<br />
This area contains the components that allow the searching and selection of data set elements. For example, microarray sets have phenotype and gene (probe) selector panels.<br />
<br />
=== Visual Area ===<br />
<br />
[[Image:VisualArea.png]]<br />
<br />
This area contains visualization components for the data set currently selected. Large, self-contained components will also likely appear in this area.<br />
<br />
=== Command Area ===<br />
<br />
[[Image:CommandArea.png]]<br />
<br />
Analysis components and other miscellaneous components are found in the Command Area. Many of these anlyses result in the creation of ancillary data sets which appear in the Project Panel.<br />
<br />
== Component Model ==<br />
<br />
File filters, anlyses and visual plug-ins are all ''components'' in geWorkbench. This section will cover the basics of the component model by developing a simple example component.<br />
<br />
=== Example Component ===<br />
<br />
A simple visual component that operates on microarray sets will be developed. A ''microarray set'' is a set of related microarray experiments, each operating on the same chip type and with the same probes. The example component will simply display the number of microarrays in the microarray set as well as the number of markers (probes).<br />
<br />
[[Image:ExampleComponent.gif]]<br />
<br />
=== The Source ===<br />
<br />
Here is the source for the example component in its entirety. The code will be examined in detail in the following sections.<br />
<br />
<pre><br />
@AcceptTypes({DSMicroarraySet.class})<br />
public class ExampleComponent extends JPanel implements VisualPlugin {<br />
<br />
private DSMicroarraySet microarraySet;<br />
private JLabel infoLabel;<br />
<br />
public ExampleComponent() {<br />
infoLabel = new JLabel("");<br />
add(infoLabel);<br />
}<br />
<br />
public Component getComponent() {<br />
// In this case, this object is also the GUI component.<br />
return this;<br />
}<br />
<br />
@Subscribe public void receive(ProjectEvent event, Object source) {<br />
DSDataSet dataSet = event.getDataSet();<br />
// We will act on this object if it is a DSMicroarraySet<br />
if (dataSet instanceof DSMicroarraySet) {<br />
microarraySet = (DSMicroarraySet) dataSet;<br />
// We just received a new microarray set, <br />
// so populate the info label with some basic stats.<br />
String htmlText = "<html><body>"<br />
+ "<h3>" + microarraySet.getLabel() + "</h3><br>"<br />
+ "<table>"<br />
+ "<tr><td>Arrays:</td><td><b>" + microarraySet.size() <br />
+ "</b></td></tr>"<br />
+ "<tr><td>Markers:</td><td><b>"<br />
+ microarraySet.getMarkers().size() <br />
+ "</b></td></tr>"<br />
+ "</table>"<br />
+ "</body></html>";<br />
infoLabel.setText(htmlText);<br />
}<br />
}<br />
}<br />
</pre><br />
<br />
=== Class Declaration ===<br />
<br />
<pre><br />
@AcceptTypes({DSMicroarraySet.class})<br />
public class ExampleComponent extends JPanel implements VisualPlugin {<br />
</pre><br />
<br />
The class declaration is prefixed with a Java 1.5 annotation called <code>AcceptTypes</code>. This annotation indicates what data sets on which this plugin will operate. It takes an array of <code>java.lang.Class</code> parameters. Each class specified must be assignable to <code>DSDataSet</code>, the root class of all data sets. Leaving the annotation out completely will result in the component to be present in the interface at all times.<br />
<br />
The declaration itself indicates that the components implements <code>VisualPlugin</code>. This interface specifies that the component is visual. Non-visual components such as file filters and analyses do not implement this interface.<br />
<br />
=== Fields and Constructor ===<br />
<br />
<pre><br />
private DSMicroarraySet microarraySet;<br />
private JLabel infoLabel;<br />
<br />
public ExampleComponent() {<br />
infoLabel = new JLabel("");<br />
add(infoLabel);<br />
}<br />
</pre><br />
<br />
A no-arg constructor is required, as the component will be instantiated by the application engine.<br />
<br />
=== VisualPlugin ===<br />
<br />
<pre><br />
public Component getComponent() {<br />
// In this case, this object is also the GUI component.<br />
return this;<br />
}<br />
</pre><br />
<br />
This method is the realization of the <code>VisualPlugin</code> interface. The application engine calls this to acquire the <code>java.awt.Component</code>. In this case, the component itself is a <code>JPanel</code>, so it is simply returned. This method should always return the same object for the lifecycle of the instance.<br />
<br />
=== @Subscribe Methods ===<br />
<br />
<pre><br />
@Subscribe public void receive(ProjectEvent event, Object source) {<br />
...<br />
}<br />
</pre><br />
<br />
Methods annotated with <code>@Subscribe</code> are called by geWorkbench when an object of the appropriate type is published. In this case, the method will be called by the engine when another component publishes an object of type <code>ProjectEvent</code>. The second parameter to the method is the publishing compoent itself, although this should rarely be needed. A method annotated with <code>@Subscribe</code> that does not take exactly two parameters will cause an error.<br />
<br />
The <code>ProjectEvent</code> is published by the Project Panel. It is published upon the selection of a data set. Almost all components will subscribe to this kind of event.<br />
<br />
A project event is handled by introspecting the data set and then acting upon it:<br />
<br />
<pre><br />
@Subscribe public void receive(ProjectEvent event, Object source) {<br />
DSDataSet dataSet = event.getDataSet();<br />
// We will act on this object if it is a DSMicroarraySet<br />
if (dataSet instanceof DSMicroarraySet) {<br />
microarraySet = (DSMicroarraySet) dataSet;<br />
...<br />
}<br />
}<br />
</pre><br />
<br />
In the above case, events for data sets other than <code>DSMicroarraySet</code> are ignored. A subscriber for project events should always check the type of received data sets regardless of what is specified in the <code>@AcceptTypes</code> annotation.<br />
<br />
=== The Details ===<br />
<br />
<pre><br />
@Subscribe public void receive(ProjectEvent event, Object source) {<br />
DSDataSet dataSet = event.getDataSet();<br />
// We will act on this object if it is a DSMicroarraySet<br />
if (dataSet instanceof DSMicroarraySet) {<br />
microarraySet = (DSMicroarraySet) dataSet;<br />
// We just received a new microarray set, <br />
// so populate the info label with some basic stats.<br />
String htmlText = "<html><body>"<br />
+ "<h3>" + microarraySet.getLabel() + "</h3><br>"<br />
+ "<table>"<br />
+ "<tr><td>Arrays:</td><td><b>" + microarraySet.size() <br />
+ "</b></td></tr>"<br />
+ "<tr><td>Markers:</td><td><b>"<br />
+ microarraySet.getMarkers().size() <br />
+ "</b></td></tr>"<br />
+ "</table>"<br />
+ "</body></html>";<br />
infoLabel.setText(htmlText);<br />
}<br />
}<br />
</pre><br />
<br />
In this code snippet, the number of arrays and markers are extracted and displayed in an HTML label. Note that this is rendered every time a microarray set is selected in the project panel.<br />
<br />
Again, the screenshot of the component at work:<br />
<br />
[[Image:ExampleComponent.gif]]<br />
<br />
== Component Resources ==<br />
<br />
Once one or more related components are written, they are combined in to ''component resources'' for deployment to geWorkbench. This is just a simple directory structure, similar to WAR files in web applications.<br />
<br />
[[Image:ResourceStructure.png]]<br />
<br />
A directory is created in the <tt>components</tt> subdirectory. In this case, it is called <tt>example</tt>. In this directory is a <tt>lib</tt> folder, which contains jar files that are needed by the component. Note that jar files that are required by the component but are already present in geWorkbench's main lib directory need not be included here, although it does no harm. Also in this directory is a <tt>classes</tt> directory, which contains the compiled classes for the component as well as any property or resource files required for the component to function.<br />
<br />
The geWorkbench engine will instantiate a new classloader for each component. This classloader will resolve classes as follows:<br />
<br />
# Component's <tt>classes</tt> directory.<br />
# Component's <tt>lib</tt> directory.<br />
# geWorkbench's classloader.<br />
<br />
Component resource files can also be packaged up in to ''GEAR'' files ('''ge'''Workbench '''Ar'''chive) for easy download and deployment. See the section on [[.GEAR files|GEAR files]] for more information.<br />
<br />
== Configuration ==<br />
<br />
Configuration of the application is controlled by XML files, including one main xml file and one xml file for each plugin component. The main xml file can be specified as a command-line argument to geWorkbench, or a default XML file will be chosen if none is specified. A schema for this configuration file is available. See <tt>geWorkbench/src/org/geworkbench/engine/config</tt> for some example configuration files.<br />
<br />
A typical configuration directive for the above exmaple component is as follows:<br />
<br />
<pre><br />
<plugin id="Example" name="Example" <br />
class="org.geworkbench.components.example.ExampleComponent" <br />
source="example"><br />
<gui-area name="VisualArea"/><br />
</plugin><br />
</pre><br />
<br />
* Components are made available to the application via the <tt>&lt;plugin&gt;</tt> element.<br />
* The <tt>id</tt> attribute is just a unique identifier for the component.<br />
* The <tt>name</tt> attribute is the name that appears in the interface (if visual).<br />
* The <tt>class</tt> attribute is the full class name of the component.<br />
* The <tt>source</tt> attribute is the resource directory where the component can be found.<br />
* The <tt>&lt;gui-area&gt;</tt> element is used to define how the component should be displayed. It is for visual components only. In this case, we put the component in to the main visual area of the application.</div>Zjihttp://wiki.c2b2.columbia.edu/workbench/index.php?title=Collaborative_Development&diff=6111Collaborative Development2010-03-23T16:16:50Z<p>Zji: </p>
<hr />
<div>{{DevelopersTopNav}}<br />
<br />
We encourage developers of geWorkbench plugins to use our code repository. Our source code tree comprises 2 separate modules under ''geworkbench'', ''src'' for the core and ''components'' for the plugin code portions as outlined in the "[[Developers]]" section. <br />
<br />
Collaborative development typically takes place under the components module. The module contains a number of subdirectories, each corresponding to one geWorkbench component package, which can contain one of more related component plugins. Each subdirectory has the same basic structure:<br />
* A '''src''' directory containing the plugin code.<br />
* An optional '''lib''' directory containing jar files required by the plugin.<br />
<br />
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). <br />
<br />
A full development environment can be then obtained by checking out the the project "geWorkbench" and one project for each subdirectory under "components". In this development space the plugin development team will be able to change the code of their plugin as they please, check it out of subversion.</div>Zjihttp://wiki.c2b2.columbia.edu/workbench/index.php?title=.GEAR_files&diff=6110.GEAR files2010-03-23T16:11:14Z<p>Zji: </p>
<hr />
<div>__NOEDITSECTION__<br />
{{DevelopersTopNav}}<br />
<br />
<br />
== Overview ==<br />
<br />
.GEAR files are essentially zipped versions of geWorkBench component plugins. They make it easy to distribute reasonably sized upgrades to specific parts of the application. They are the geWorkbench analogue of .WAR files for web applications.<br />
<br />
== Creating a .GEAR file ==<br />
<br />
There is an ant task that will create a .GEAR file automatically. Run ant with “ant –Dcomponent=NAME” which will create a .gear file from the specified component directory. You can also run the Windows batch file “makeGear NAME” instead. Put the resulting .gear file in the components directory of a geWorkbench installation and it will be loaded by the application.<br />
<br />
== Viewing loaded versions of components ==<br />
<br />
The menu item "Tools->Component Configuration" will list all the loaded versions of component plugins. The subdirectories and gear files under the component directory are loaded similarly.</div>Zjihttp://wiki.c2b2.columbia.edu/workbench/index.php?title=Developers&diff=6100Developers2010-03-22T16:17:42Z<p>Zji: </p>
<hr />
<div>{{DevelopersTopNav}}<br />
<br />
geWorkbench is an open source Java-based platform and contributions by members of the community are welcome and encouraged. The latest code under development can be found at NCI's subversion server, https://ncisvn.nci.nih.gov/svn/geworkbench/. Anonymous read access is supported for all the code.<br />
<br />
<br />
Development in geWorkbench takes place along 2 parallel axes:<br />
* <u>'''geWorkbench core'''</u>: this portion of the code includes mainly 2 groups of packages: ''engine'', which implements services related to the geWorkbench component architecture framework (e.g., plugin instantiation and visual layout, message delivery, component registry management, etc); and, ''bison'' ('''B'''iomedical '''I'''nformatics '''S'''tructured '''ON'''tology) which contains the definition of the bioinformatics data types which form the basis of communication between the geWorkbench plugins.<br />
* <u>'''geWorkbench plugins'''</u>: this portion of the source tree contains the code for the various application plugin components (sample code for creating a simple plugin can be found [[A_Simple_Plugin |here]]).<br />
<br />
There are no restrictions on who can develop a new component for geWorkbench. You can work against the development version or a release version of the geWorkbench core. To contribute your component to geWorkbench code, you need write access to the subversion server. Please contact us for the procedure.<br />
Contributions to the geWorkbench core packages are more controlled in order to avoid changes that may adversely affect large numbers of plugins.</div>Zjihttp://wiki.c2b2.columbia.edu/workbench/index.php?title=Software_Development_Kit&diff=6099Software Development Kit2010-03-22T15:57:46Z<p>Zji: /* Configure Plugin */</p>
<hr />
<div>{{DevelopersTopNav}}<br />
<br />
The Development Kit is a self-contained package that facilitates the process of developing plugins for geWorkbench. <br />
<br />
== Using the Development Kit ==<br />
<br />
The Development Kit is available as a .zip file (see [[Download]] page). Unzip this archive, then follow the instructions below to create a geWorkbench plugin. Prerequisites to using the SDK are installing [http://ant.apache.org/manual/index.html ANT] and a [[Download#Software_Requirements|supported version]] of Java.<br />
<br />
The high-level steps for creating, testing and releasing a plugin are as follows:<br />
<br />
# From the command line, ''cd'' into the directory created after unpacking the archive.<br />
# Edit the provided Apache Ant build script to specify the name of your plugin.<br />
# Add the .java source files for your plugin to the <tt>src</tt> directory.<br />
# Add any .jar libraries that your plugin requires to the <tt>lib</tt> directory.<br />
# Run <tt>ant</tt> to build your plugin.<br />
# Edit the geWorkbench configuration file to add a directive for your new plugin.<br />
# Run geWorkbench with <tt>ant run</tt> to test your plugin.<br />
# Once satisfied with your plugin, use the provided utility to package your plugin in to a single file for distribution.<br />
<br />
The next section will illustrate the above steps with an example.<br />
<br />
== An Example Plugin (geworkbench 1.7) ==<br />
<br />
We will create an example plugin that is simply called <tt>test</tt>. This will be a very simple visualization plugin that just displays a blank blue region.<br />
<br />
=== Setting the Plugin Name ===<br />
<br />
In the provided <tt>build.xml</tt>, change this line:<br />
<br />
<property name="component" value="noname"/><br />
<br />
to:<br />
<br />
<property name="component" value="test"/><br />
<br />
This specifies the name of our component, which is used for all build products.<br />
<br />
=== Adding Source ===<br />
<br />
Next, create and add a single .java source file to the org.organization.test package. To do this, first, create the file <tt>TestComponent.java</tt> (in your favorite editor) and copy and paste the code below in this file. Then, create the directories <tt>src/org/organization/test</tt> in /src and place <tt>TestComponent.java</tt> file in this directory.<br />
<br />
package org.organization.test;<br />
<br />
import org.geworkbench.engine.config.VisualPlugin;<br />
<br />
import javax.swing.*;<br />
import java.awt.*;<br />
<br />
/**<br />
* A simple demonstration component.<br />
*/<br />
public class TestComponent implements VisualPlugin {<br />
<br />
private JPanel panel;<br />
<br />
public TestComponent() {<br />
panel = new JPanel();<br />
panel.setBackground(Color.blue);<br />
}<br />
<br />
public Component getComponent() {<br />
return panel;<br />
}<br />
}<br />
<br />
If the component requires any .jar files, add them to the <tt>lib</tt> directory.<br />
<br />
=== Configure Plugin ===<br />
<br />
Create a .cwb.xml file for your plugin and place it under the same directory as the source file. In this case, create ''test.cwb.xml'' and place it under ''GEWORKBENCHSDK_HOME/src/org/organization/test''.<br />
<br />
<geaw-config xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="ConfigurationFile Schema.xsd"><br />
<component name="Test SDK Panel" <br />
class="org.organization.test.TestComponent" <br />
version="1.0"<br />
author="C2B2"<br />
authorURL=""<br />
toolURL=""<br />
description="test SDK"<br />
visualizer="true"><br />
<license><br />
<![CDATA[<br />
<html><head><meta http-equiv=Content-Type content="text/html; charset=windows-1252"></head><br />
<body>----</body><br />
</html><br />
]]></license><br />
</component><br />
<plugin id="TestSDKPanel" name="Test SDK" class="org.organization.test.TestComponent" source="test"><br />
<gui-area name="VisualArea"/><br />
</plugin><br />
</geaw-config><br />
<br />
=== Running the Plugin in geWorkbench ===<br />
<br />
To run the plugin and see it appear in geWorkbench (a blue visual), do the following:<br />
<br />
ant run<br />
<br />
When geWorkbench appears, right click on the ''Workspace'' and select ''New Project''. You should see the blue visual plugin.<br />
<br />
=== Releasing the Plugin ===<br />
<br />
To create a plugin release, type:<br />
<br />
ant gear<br />
<br />
This creates the file <tt>test.gear</tt>. This gear file is a bundled plugin that can deployed to a geWorkbench installation by placing the file in the <tt>components</tt> directory, then unzipping it.<br />
<br />
== An Example Plugin (Pre geworkbench 1.7) ==<br />
<br />
We will create an example plugin that is simply called <tt>test</tt>. This will be a very simple visualization plugin that just displays a blank blue region.<br />
<br />
=== Setting the Plugin Name ===<br />
<br />
In the provided <tt>build.xml</tt>, change this line:<br />
<br />
<property name="component" value="noname"/><br />
<br />
to:<br />
<br />
<property name="component" value="test"/><br />
<br />
This specifies the name of our component, which is used for all build products.<br />
<br />
=== Adding Source ===<br />
<br />
Next, create and add a single .java source file to the org.organization.test package. To do this, first, create the file <tt>TestComponent.java</tt> (in your favorite editor) and copy and paste the code below in this file. Then, create the directories <tt>src/org/organization/test</tt> in /src and place <tt>TestComponent.java</tt> file in this directory.<br />
<br />
package org.organization.test;<br />
<br />
import org.geworkbench.engine.config.VisualPlugin;<br />
<br />
import javax.swing.*;<br />
import java.awt.*;<br />
<br />
/**<br />
* A simple demonstration component.<br />
*/<br />
public class TestComponent implements VisualPlugin {<br />
<br />
private JPanel panel;<br />
<br />
public TestComponent() {<br />
panel = new JPanel();<br />
panel.setBackground(Color.blue);<br />
}<br />
<br />
public Component getComponent() {<br />
return panel;<br />
}<br />
}<br />
<br />
If the component requires any .jar files, add them to the <tt>lib</tt> directory.<br />
<br />
=== Configure Plugin ===<br />
<br />
The configuration file for the Development Kit is called <tt>minimal.xml</tt> and it is in the <tt>conf</tt> directory. <br />
<br />
Add the following to the bottom of <tt>minimal.xml</tt> (before ''</geaw-config>''):<br />
<br />
<plugin id="testPanel" name="Test Panel" class="org.organization.test.TestComponent" source="test"><br />
<gui-area name="VisualArea"/><br />
</plugin><br />
<br />
=== Running the Plugin in geWorkbench ===<br />
<br />
To run the plugn and see it appear in geWorkbench (a blue visual), do the following:<br />
<br />
ant run<br />
<br />
When geWorkbench appears, right click on the ''Workspace'' and select ''New Project''. You should see the blue visual plugin.<br />
<br />
=== Releasing the Plugin ===<br />
<br />
To create a plugin release, type:<br />
<br />
ant gear<br />
<br />
This creates the file <tt>test.gear</tt>. A .gear file is the geWorkbench analogue of a .war file for a web application. Is a bundled plugin that can deployed to a geWorkbench install by placing the file in the <tt>components</tt> directory. A configuration directive (such as the one above) would also need to be added to the configuration file to activate the plugin.</div>Zjihttp://wiki.c2b2.columbia.edu/workbench/index.php?title=Developers&diff=6098Developers2010-03-22T15:53:36Z<p>Zji: </p>
<hr />
<div>{{DevelopersTopNav}}<br />
<br />
geWorkbench is an open source Java-based platform and contributions by members of the community are welcome and encouraged. The latest code under development can be found at NCI's subversion server, https://ncisvn.nci.nih.gov/svn/geworkbench/. Anonymous read access is supported for all the code.<br />
<br />
<br />
Development in geWorkbench takes place along 2 parallel axes:<br />
* <u>'''geWorkbench core'''</u>: this portion of the code includes mainly 2 groups of packages: ''engine'', which implements services related to the geWorkbench component architecture framework (e.g., plugin instantiation and visual layout, message delivery, component registry management, etc); and, ''bison'' ('''B'''iomedical '''I'''nformatics '''S'''tructured '''ON'''tology) which contains the definition of the bioinformatics data types which form the basis of communication between the geWorkbench plugins.<br />
* <u>'''geWorkbench plugins'''</u>: this portion of the source tree contains the code for the various application plugin components (sample code for creating a simple plugin can be found [[A_Simple_Plugin |here]]).<br />
<br />
Contributing a new geWorkbench component is a straightforward process: First you would request space in the project's CVS server (using the "Request to join" link from the gForge page). This allows you to work against the development version of the geWorkbench core. There are no restrictions on who can develop and submit a new component. On the other hand contributions to the geWorkbench core packages are controlled in order to avoid changes that may adversely affect large numbers of plugins.</div>Zji