geWorkbench - User contributions [en]

Software Development Kit

2009-07-23T20:39:52Z

Keshav: /* Releasing the Plugin */

{{DevelopersTopNav}}

The Development Kit is a self-contained package that facilitates the process of developing plugins for geWorkbench.

== Using the Development Kit ==

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.

The high-level steps for creating, testing and releasing a plugin are as follows:

# From the command line, ''cd'' into the directory created after unpacking the archive.
# Edit the provided Apache Ant build script to specify the name of your plugin.
# Add the .java source files for your plugin to the <tt>src</tt> directory.
# Add any .jar libraries that your plugin requires to the <tt>lib</tt> directory.
# Run <tt>ant</tt> to build your plugin.
# Edit the geWorkbench configuration file to add a directive for your new plugin.
# Run geWorkbench with <tt>ant run</tt> to test your plugin.
# Once satisfied with your plugin, use the provided utility to package your plugin in to a single file for distribution.

The next section will illustrate the above steps with an example.

== An Example Plugin (geworkbench 1.7) ==

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.

=== Setting the Plugin Name ===

In the provided <tt>build.xml</tt>, change this line:

<property name="component" value="noname"/>

to:

<property name="component" value="test"/>

This specifies the name of our component, which is used for all build products.

=== Adding Source ===

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.

package org.organization.test;

import org.geworkbench.engine.config.VisualPlugin;

import javax.swing.*;
import java.awt.*;

/**
* A simple demonstration component.
*/
public class TestComponent implements VisualPlugin {

private JPanel panel;

public TestComponent() {
panel = new JPanel();
panel.setBackground(Color.blue);
}

public Component getComponent() {
return panel;
}
}

If the component requires any .jar files, add them to the <tt>lib</tt> directory.

=== Configure Plugin ===

Create a .ccm.xml file for your plugin and place it under /src. In this case, create ''test.ccm.xml'' and place it under ''GEWORKBENCHSDK_HOME/src''.

<geaw-config xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="ConfigurationFile Schema.xsd">
<component name="Test SDK Panel"
class="org.organization.test.TestComponent"
version="1.0"
author="C2B2"
authorURL=""
toolURL=""
description="test SDK"
visualizer="true">
<license>
<![CDATA[
<html><head><meta http-equiv=Content-Type content="text/html; charset=windows-1252"></head>
<body>----</body>
</html>
]]></license>
</component>
<plugin id="TestSDKPanel" name="Test SDK" class="org.organization.test.TestComponent" source="test">
<gui-area name="VisualArea"/>
</plugin>
</geaw-config>

=== Running the Plugin in geWorkbench ===

To run the plugin and see it appear in geWorkbench (a blue visual), do the following:

ant run

When geWorkbench appears, right click on the ''Workspace'' and select ''New Project''. You should see the blue visual plugin.

=== Releasing the Plugin ===

To create a plugin release, type:

ant gear

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.

== An Example Plugin (Pre geworkbench 1.7) ==

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.

=== Setting the Plugin Name ===

In the provided <tt>build.xml</tt>, change this line:

<property name="component" value="noname"/>

to:

<property name="component" value="test"/>

This specifies the name of our component, which is used for all build products.

=== Adding Source ===

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.

package org.organization.test;

import org.geworkbench.engine.config.VisualPlugin;

import javax.swing.*;
import java.awt.*;

/**
* A simple demonstration component.
*/
public class TestComponent implements VisualPlugin {

private JPanel panel;

public TestComponent() {
panel = new JPanel();
panel.setBackground(Color.blue);
}

public Component getComponent() {
return panel;
}
}

If the component requires any .jar files, add them to the <tt>lib</tt> directory.

=== Configure Plugin ===

The configuration file for the Development Kit is called <tt>minimal.xml</tt> and it is in the <tt>conf</tt> directory.

Add the following to the bottom of <tt>minimal.xml</tt> (before ''</geaw-config>''):

<plugin id="testPanel" name="Test Panel" class="org.organization.test.TestComponent" source="test">
<gui-area name="VisualArea"/>
</plugin>

=== Running the Plugin in geWorkbench ===

To run the plugn and see it appear in geWorkbench (a blue visual), do the following:

ant run

When geWorkbench appears, right click on the ''Workspace'' and select ''New Project''. You should see the blue visual plugin.

=== Releasing the Plugin ===

To create a plugin release, type:

ant gear

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.

Software Development Kit

2009-07-23T20:36:08Z

Keshav: /* Running the Plugin in geWorkbench */

{{DevelopersTopNav}}

The Development Kit is a self-contained package that facilitates the process of developing plugins for geWorkbench.

== Using the Development Kit ==

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.

The high-level steps for creating, testing and releasing a plugin are as follows:

# From the command line, ''cd'' into the directory created after unpacking the archive.
# Edit the provided Apache Ant build script to specify the name of your plugin.
# Add the .java source files for your plugin to the <tt>src</tt> directory.
# Add any .jar libraries that your plugin requires to the <tt>lib</tt> directory.
# Run <tt>ant</tt> to build your plugin.
# Edit the geWorkbench configuration file to add a directive for your new plugin.
# Run geWorkbench with <tt>ant run</tt> to test your plugin.
# Once satisfied with your plugin, use the provided utility to package your plugin in to a single file for distribution.

The next section will illustrate the above steps with an example.

== An Example Plugin (geworkbench 1.7) ==

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.

=== Setting the Plugin Name ===

In the provided <tt>build.xml</tt>, change this line:

<property name="component" value="noname"/>

to:

<property name="component" value="test"/>

This specifies the name of our component, which is used for all build products.

=== Adding Source ===

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.

package org.organization.test;

import org.geworkbench.engine.config.VisualPlugin;

import javax.swing.*;
import java.awt.*;

/**
* A simple demonstration component.
*/
public class TestComponent implements VisualPlugin {

private JPanel panel;

public TestComponent() {
panel = new JPanel();
panel.setBackground(Color.blue);
}

public Component getComponent() {
return panel;
}
}

If the component requires any .jar files, add them to the <tt>lib</tt> directory.

=== Configure Plugin ===

Create a .ccm.xml file for your plugin and place it under /src. In this case, create ''test.ccm.xml'' and place it under ''GEWORKBENCHSDK_HOME/src''.

<geaw-config xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="ConfigurationFile Schema.xsd">
<component name="Test SDK Panel"
class="org.organization.test.TestComponent"
version="1.0"
author="C2B2"
authorURL=""
toolURL=""
description="test SDK"
visualizer="true">
<license>
<![CDATA[
<html><head><meta http-equiv=Content-Type content="text/html; charset=windows-1252"></head>
<body>----</body>
</html>
]]></license>
</component>
<plugin id="TestSDKPanel" name="Test SDK" class="org.organization.test.TestComponent" source="test">
<gui-area name="VisualArea"/>
</plugin>
</geaw-config>

=== Running the Plugin in geWorkbench ===

To run the plugin and see it appear in geWorkbench (a blue visual), do the following:

ant run

When geWorkbench appears, right click on the ''Workspace'' and select ''New Project''. You should see the blue visual plugin.

=== Releasing the Plugin ===

To create a plugin release, type:

ant gear

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.

== An Example Plugin (Pre geworkbench 1.7) ==

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.

=== Setting the Plugin Name ===

In the provided <tt>build.xml</tt>, change this line:

<property name="component" value="noname"/>

to:

<property name="component" value="test"/>

This specifies the name of our component, which is used for all build products.

=== Adding Source ===

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.

package org.organization.test;

import org.geworkbench.engine.config.VisualPlugin;

import javax.swing.*;
import java.awt.*;

/**
* A simple demonstration component.
*/
public class TestComponent implements VisualPlugin {

private JPanel panel;

public TestComponent() {
panel = new JPanel();
panel.setBackground(Color.blue);
}

public Component getComponent() {
return panel;
}
}

If the component requires any .jar files, add them to the <tt>lib</tt> directory.

=== Configure Plugin ===

The configuration file for the Development Kit is called <tt>minimal.xml</tt> and it is in the <tt>conf</tt> directory.

Add the following to the bottom of <tt>minimal.xml</tt> (before ''</geaw-config>''):

<plugin id="testPanel" name="Test Panel" class="org.organization.test.TestComponent" source="test">
<gui-area name="VisualArea"/>
</plugin>

=== Running the Plugin in geWorkbench ===

To run the plugn and see it appear in geWorkbench (a blue visual), do the following:

ant run

When geWorkbench appears, right click on the ''Workspace'' and select ''New Project''. You should see the blue visual plugin.

=== Releasing the Plugin ===

To create a plugin release, type:

ant gear

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.

Software Development Kit

2009-07-23T20:35:57Z

Keshav: /* Configure Plugin */

{{DevelopersTopNav}}

The Development Kit is a self-contained package that facilitates the process of developing plugins for geWorkbench.

== Using the Development Kit ==

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.

The high-level steps for creating, testing and releasing a plugin are as follows:

# From the command line, ''cd'' into the directory created after unpacking the archive.
# Edit the provided Apache Ant build script to specify the name of your plugin.
# Add the .java source files for your plugin to the <tt>src</tt> directory.
# Add any .jar libraries that your plugin requires to the <tt>lib</tt> directory.
# Run <tt>ant</tt> to build your plugin.
# Edit the geWorkbench configuration file to add a directive for your new plugin.
# Run geWorkbench with <tt>ant run</tt> to test your plugin.
# Once satisfied with your plugin, use the provided utility to package your plugin in to a single file for distribution.

The next section will illustrate the above steps with an example.

== An Example Plugin (geworkbench 1.7) ==

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.

=== Setting the Plugin Name ===

In the provided <tt>build.xml</tt>, change this line:

<property name="component" value="noname"/>

to:

<property name="component" value="test"/>

This specifies the name of our component, which is used for all build products.

=== Adding Source ===

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.

package org.organization.test;

import org.geworkbench.engine.config.VisualPlugin;

import javax.swing.*;
import java.awt.*;

/**
* A simple demonstration component.
*/
public class TestComponent implements VisualPlugin {

private JPanel panel;

public TestComponent() {
panel = new JPanel();
panel.setBackground(Color.blue);
}

public Component getComponent() {
return panel;
}
}

If the component requires any .jar files, add them to the <tt>lib</tt> directory.

=== Configure Plugin ===

Create a .ccm.xml file for your plugin and place it under /src. In this case, create ''test.ccm.xml'' and place it under ''GEWORKBENCHSDK_HOME/src''.

<geaw-config xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="ConfigurationFile Schema.xsd">
<component name="Test SDK Panel"
class="org.organization.test.TestComponent"
version="1.0"
author="C2B2"
authorURL=""
toolURL=""
description="test SDK"
visualizer="true">
<license>
<![CDATA[
<html><head><meta http-equiv=Content-Type content="text/html; charset=windows-1252"></head>
<body>----</body>
</html>
]]></license>
</component>
<plugin id="TestSDKPanel" name="Test SDK" class="org.organization.test.TestComponent" source="test">
<gui-area name="VisualArea"/>
</plugin>
</geaw-config>

=== Running the Plugin in geWorkbench ===

To run the plugn and see it appear in geWorkbench (a blue visual), do the following:

ant run

When geWorkbench appears, right click on the ''Workspace'' and select ''New Project''. You should see the blue visual plugin.

=== Releasing the Plugin ===

To create a plugin release, type:

ant gear

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.

== An Example Plugin (Pre geworkbench 1.7) ==

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.

=== Setting the Plugin Name ===

In the provided <tt>build.xml</tt>, change this line:

<property name="component" value="noname"/>

to:

<property name="component" value="test"/>

This specifies the name of our component, which is used for all build products.

=== Adding Source ===

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.

package org.organization.test;

import org.geworkbench.engine.config.VisualPlugin;

import javax.swing.*;
import java.awt.*;

/**
* A simple demonstration component.
*/
public class TestComponent implements VisualPlugin {

private JPanel panel;

public TestComponent() {
panel = new JPanel();
panel.setBackground(Color.blue);
}

public Component getComponent() {
return panel;
}
}

If the component requires any .jar files, add them to the <tt>lib</tt> directory.

=== Configure Plugin ===

The configuration file for the Development Kit is called <tt>minimal.xml</tt> and it is in the <tt>conf</tt> directory.

Add the following to the bottom of <tt>minimal.xml</tt> (before ''</geaw-config>''):

<plugin id="testPanel" name="Test Panel" class="org.organization.test.TestComponent" source="test">
<gui-area name="VisualArea"/>
</plugin>

=== Running the Plugin in geWorkbench ===

To run the plugn and see it appear in geWorkbench (a blue visual), do the following:

ant run

When geWorkbench appears, right click on the ''Workspace'' and select ''New Project''. You should see the blue visual plugin.

=== Releasing the Plugin ===

To create a plugin release, type:

ant gear

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.

Software Development Kit

2009-07-23T20:34:55Z

Keshav: /* Configure Plugin */

{{DevelopersTopNav}}

The Development Kit is a self-contained package that facilitates the process of developing plugins for geWorkbench.

== Using the Development Kit ==

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.

The high-level steps for creating, testing and releasing a plugin are as follows:

# From the command line, ''cd'' into the directory created after unpacking the archive.
# Edit the provided Apache Ant build script to specify the name of your plugin.
# Add the .java source files for your plugin to the <tt>src</tt> directory.
# Add any .jar libraries that your plugin requires to the <tt>lib</tt> directory.
# Run <tt>ant</tt> to build your plugin.
# Edit the geWorkbench configuration file to add a directive for your new plugin.
# Run geWorkbench with <tt>ant run</tt> to test your plugin.
# Once satisfied with your plugin, use the provided utility to package your plugin in to a single file for distribution.

The next section will illustrate the above steps with an example.

== An Example Plugin (geworkbench 1.7) ==

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.

=== Setting the Plugin Name ===

In the provided <tt>build.xml</tt>, change this line:

<property name="component" value="noname"/>

to:

<property name="component" value="test"/>

This specifies the name of our component, which is used for all build products.

=== Adding Source ===

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.

package org.organization.test;

import org.geworkbench.engine.config.VisualPlugin;

import javax.swing.*;
import java.awt.*;

/**
* A simple demonstration component.
*/
public class TestComponent implements VisualPlugin {

private JPanel panel;

public TestComponent() {
panel = new JPanel();
panel.setBackground(Color.blue);
}

public Component getComponent() {
return panel;
}
}

If the component requires any .jar files, add them to the <tt>lib</tt> directory.

=== Configure Plugin ===

Create a .ccm.xml file for your plugin and place it under /src. In this case, create ''test.ccm.xml'' and place it under GEWORKBENCHSDK_HOME/src.

<geaw-config xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="ConfigurationFile Schema.xsd">
<component name="Test SDK Panel"
class="org.organization.test.TestComponent"
version="1.0"
author="C2B2"
authorURL=""
toolURL=""
description="test SDK"
visualizer="true">
<license>
<![CDATA[
<html><head><meta http-equiv=Content-Type content="text/html; charset=windows-1252"></head>
<body>----</body>
</html>
]]></license>
</component>
<plugin id="TestSDKPanel" name="Test SDK" class="org.organization.test.TestComponent" source="test">
<gui-area name="VisualArea"/>
</plugin>
</geaw-config>

=== Running the Plugin in geWorkbench ===

To run the plugn and see it appear in geWorkbench (a blue visual), do the following:

ant run

When geWorkbench appears, right click on the ''Workspace'' and select ''New Project''. You should see the blue visual plugin.

=== Releasing the Plugin ===

To create a plugin release, type:

ant gear

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.

== An Example Plugin (Pre geworkbench 1.7) ==

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.

=== Setting the Plugin Name ===

In the provided <tt>build.xml</tt>, change this line:

<property name="component" value="noname"/>

to:

<property name="component" value="test"/>

This specifies the name of our component, which is used for all build products.

=== Adding Source ===

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.

package org.organization.test;

import org.geworkbench.engine.config.VisualPlugin;

import javax.swing.*;
import java.awt.*;

/**
* A simple demonstration component.
*/
public class TestComponent implements VisualPlugin {

private JPanel panel;

public TestComponent() {
panel = new JPanel();
panel.setBackground(Color.blue);
}

public Component getComponent() {
return panel;
}
}

If the component requires any .jar files, add them to the <tt>lib</tt> directory.

=== Configure Plugin ===

The configuration file for the Development Kit is called <tt>minimal.xml</tt> and it is in the <tt>conf</tt> directory.

Add the following to the bottom of <tt>minimal.xml</tt> (before ''</geaw-config>''):

<plugin id="testPanel" name="Test Panel" class="org.organization.test.TestComponent" source="test">
<gui-area name="VisualArea"/>
</plugin>

=== Running the Plugin in geWorkbench ===

To run the plugn and see it appear in geWorkbench (a blue visual), do the following:

ant run

When geWorkbench appears, right click on the ''Workspace'' and select ''New Project''. You should see the blue visual plugin.

=== Releasing the Plugin ===

To create a plugin release, type:

ant gear

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.

Software Development Kit

2009-07-23T20:33:37Z

Keshav: /* Configure Plugin */

{{DevelopersTopNav}}

The Development Kit is a self-contained package that facilitates the process of developing plugins for geWorkbench.

== Using the Development Kit ==

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.

The high-level steps for creating, testing and releasing a plugin are as follows:

# From the command line, ''cd'' into the directory created after unpacking the archive.
# Edit the provided Apache Ant build script to specify the name of your plugin.
# Add the .java source files for your plugin to the <tt>src</tt> directory.
# Add any .jar libraries that your plugin requires to the <tt>lib</tt> directory.
# Run <tt>ant</tt> to build your plugin.
# Edit the geWorkbench configuration file to add a directive for your new plugin.
# Run geWorkbench with <tt>ant run</tt> to test your plugin.
# Once satisfied with your plugin, use the provided utility to package your plugin in to a single file for distribution.

The next section will illustrate the above steps with an example.

== An Example Plugin (geworkbench 1.7) ==

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.

=== Setting the Plugin Name ===

In the provided <tt>build.xml</tt>, change this line:

<property name="component" value="noname"/>

to:

<property name="component" value="test"/>

This specifies the name of our component, which is used for all build products.

=== Adding Source ===

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.

package org.organization.test;

import org.geworkbench.engine.config.VisualPlugin;

import javax.swing.*;
import java.awt.*;

/**
* A simple demonstration component.
*/
public class TestComponent implements VisualPlugin {

private JPanel panel;

public TestComponent() {
panel = new JPanel();
panel.setBackground(Color.blue);
}

public Component getComponent() {
return panel;
}
}

If the component requires any .jar files, add them to the <tt>lib</tt> directory.

=== Configure Plugin ===

Create a .ccm.xml file for your plugin and place it under /src. In this case, create ''test.ccm.xml'' and place it under GEWORKBENCHSDK_HOME/src.

<geaw-config xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="ConfigurationFile Schema.xsd">
<component name="Test SDK Panel"
class="org.organization.test.TestComponent"
version="1.0"
author="C2B2"
authorURL=""
toolURL=""
description="test SDK"
visualizer="true">
<license>
<![CDATA[
<html><head><meta http-equiv=Content-Type content="text/html; charset=windows-1252"></head>
<body>----</body>
</html>
]]></license>
</component>
<plugin id="TestSDKPanel" name="Test SDK" class="org.organization.test.TestComponent" source="test">
<gui-area name="VisualArea"/>
</plugin>
</geaw-config>

=== Running the Plugin in geWorkbench ===

To run the plugn and see it appear in geWorkbench (a blue visual), do the following:

ant run

When geWorkbench appears, right click on the ''Workspace'' and select ''New Project''. You should see the blue visual plugin.

=== Releasing the Plugin ===

To create a plugin release, type:

ant gear

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.

== An Example Plugin (Pre geworkbench 1.7) ==

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.

=== Setting the Plugin Name ===

In the provided <tt>build.xml</tt>, change this line:

<property name="component" value="noname"/>

to:

<property name="component" value="test"/>

This specifies the name of our component, which is used for all build products.

=== Adding Source ===

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.

package org.organization.test;

import org.geworkbench.engine.config.VisualPlugin;

import javax.swing.*;
import java.awt.*;

/**
* A simple demonstration component.
*/
public class TestComponent implements VisualPlugin {

private JPanel panel;

public TestComponent() {
panel = new JPanel();
panel.setBackground(Color.blue);
}

public Component getComponent() {
return panel;
}
}

If the component requires any .jar files, add them to the <tt>lib</tt> directory.

=== Configure Plugin ===

The configuration file for the Development Kit is called <tt>minimal.xml</tt> and it is in the <tt>conf</tt> directory.

Add the following to the bottom of <tt>minimal.xml</tt> (before ''</geaw-config>''):

<plugin id="testPanel" name="Test Panel" class="org.organization.test.TestComponent" source="test">
<gui-area name="VisualArea"/>
</plugin>

=== Running the Plugin in geWorkbench ===

To run the plugn and see it appear in geWorkbench (a blue visual), do the following:

ant run

When geWorkbench appears, right click on the ''Workspace'' and select ''New Project''. You should see the blue visual plugin.

=== Releasing the Plugin ===

To create a plugin release, type:

ant gear

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.

Software Development Kit

2009-07-23T20:31:39Z

Keshav:

{{DevelopersTopNav}}

The Development Kit is a self-contained package that facilitates the process of developing plugins for geWorkbench.

== Using the Development Kit ==

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.

The high-level steps for creating, testing and releasing a plugin are as follows:

# From the command line, ''cd'' into the directory created after unpacking the archive.
# Edit the provided Apache Ant build script to specify the name of your plugin.
# Add the .java source files for your plugin to the <tt>src</tt> directory.
# Add any .jar libraries that your plugin requires to the <tt>lib</tt> directory.
# Run <tt>ant</tt> to build your plugin.
# Edit the geWorkbench configuration file to add a directive for your new plugin.
# Run geWorkbench with <tt>ant run</tt> to test your plugin.
# Once satisfied with your plugin, use the provided utility to package your plugin in to a single file for distribution.

The next section will illustrate the above steps with an example.

== An Example Plugin (geworkbench 1.7) ==

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.

=== Setting the Plugin Name ===

In the provided <tt>build.xml</tt>, change this line:

<property name="component" value="noname"/>

to:

<property name="component" value="test"/>

This specifies the name of our component, which is used for all build products.

=== Adding Source ===

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.

package org.organization.test;

import org.geworkbench.engine.config.VisualPlugin;

import javax.swing.*;
import java.awt.*;

/**
* A simple demonstration component.
*/
public class TestComponent implements VisualPlugin {

private JPanel panel;

public TestComponent() {
panel = new JPanel();
panel.setBackground(Color.blue);
}

public Component getComponent() {
return panel;
}
}

If the component requires any .jar files, add them to the <tt>lib</tt> directory.

=== Configure Plugin ===

Create a .ccm.xml file for your plugin and place it under /src. In this case, create ''test.ccm.xml'' and place it under GEWORKBENCHSDK_HOME/src.

<geaw-config xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="ConfigurationFile Schema.xsd">
<component name="Test SDK Panel"
class="org.organization.test.TestComponent"
version="1.0"
author="C2B2"
authorURL=""
toolURL=""
description="test SDK"
visualizer="true"
>
<license><![CDATA[
<html><head><meta http-equiv=Content-Type content="text/html; charset=windows-1252"></head>
<body>----</body>
</html>
]]></license>
</component>
<plugin id="TestSDKPanel" name="Test SDK" class="org.organization.test.TestComponent" source="test">
<gui-area name="VisualArea"/>
</plugin>
</geaw-config>

=== Running the Plugin in geWorkbench ===

To run the plugn and see it appear in geWorkbench (a blue visual), do the following:

ant run

When geWorkbench appears, right click on the ''Workspace'' and select ''New Project''. You should see the blue visual plugin.

=== Releasing the Plugin ===

To create a plugin release, type:

ant gear

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.

== An Example Plugin (Pre geworkbench 1.7) ==

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.

=== Setting the Plugin Name ===

In the provided <tt>build.xml</tt>, change this line:

<property name="component" value="noname"/>

to:

<property name="component" value="test"/>

This specifies the name of our component, which is used for all build products.

=== Adding Source ===

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.

package org.organization.test;

import org.geworkbench.engine.config.VisualPlugin;

import javax.swing.*;
import java.awt.*;

/**
* A simple demonstration component.
*/
public class TestComponent implements VisualPlugin {

private JPanel panel;

public TestComponent() {
panel = new JPanel();
panel.setBackground(Color.blue);
}

public Component getComponent() {
return panel;
}
}

If the component requires any .jar files, add them to the <tt>lib</tt> directory.

=== Configure Plugin ===

The configuration file for the Development Kit is called <tt>minimal.xml</tt> and it is in the <tt>conf</tt> directory.

Add the following to the bottom of <tt>minimal.xml</tt> (before ''</geaw-config>''):

<plugin id="testPanel" name="Test Panel" class="org.organization.test.TestComponent" source="test">
<gui-area name="VisualArea"/>
</plugin>

=== Running the Plugin in geWorkbench ===

To run the plugn and see it appear in geWorkbench (a blue visual), do the following:

ant run

When geWorkbench appears, right click on the ''Workspace'' and select ''New Project''. You should see the blue visual plugin.

=== Releasing the Plugin ===

To create a plugin release, type:

ant gear

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.

Software Development Kit

2009-03-20T17:30:22Z

Keshav: /* Using the Development Kit */

Software Development Kit

2009-03-20T17:30:14Z

Keshav: /* Using the Development Kit */

Software Development Kit

2009-03-20T17:28:56Z

Keshav: /* Using the Development Kit */

Software Development Kit

2009-03-20T17:28:37Z

Keshav: /* Using the Development Kit */

Software Development Kit

2009-03-20T17:28:06Z

Keshav: /* Using the Development Kit */

Software Development Kit

2009-03-20T17:25:05Z

Keshav: /* Using the Development Kit */

Software Development Kit

2009-03-20T17:24:06Z

Keshav: /* Using the Development Kit */

Software Development Kit

2009-03-20T17:23:57Z

Keshav: /* Using the Development Kit */

Software Development Kit

2009-03-20T17:23:05Z

Keshav: /* Using the Development Kit */

Software Development Kit

2009-03-20T17:22:57Z

Keshav: /* Using the Development Kit */

Software Development Kit

2009-03-20T17:22:34Z

Keshav: /* Using the Development Kit */

Software Development Kit

2009-03-20T17:20:00Z

Keshav: /* Using the Development Kit */

Software Development Kit

2009-03-20T17:19:17Z

Keshav: /* Using the Development Kit */

Software Development Kit

2009-03-20T17:19:08Z

Keshav: /* Using the Development Kit */

Software Development Kit

2009-03-20T17:18:07Z

Keshav: /* Using the Development Kit */

Software Development Kit

2009-03-20T17:16:53Z

Keshav: /* Using the Development Kit */

Software Development Kit

2009-03-20T17:16:37Z

Keshav: /* Using the Development Kit */

Developers

2009-03-20T17:15:10Z

Keshav:

{{DevelopersTopNav}}

geWorkbench is an open source Java-based platform and contributions by members of the community are welcome and encouraged. The latest code releases as well as technical documentation can be found at the project's gForge page, http://gforge.nci.nih.gov/projects/geworkbench. There are two ways to access the project's code:
* Individuals interested in participating in the development process can click on the '''''"Request to join"''''' link at the bottom of the project page to acquire an account on the geWorkbench CVS code repository. Once this account is issued it is be possible to check code in and out of the repository.
* Read-only code access is also possible, please see the [[FAQ#download_geworkbench_code | FAQ section of the site for details]].

Development in geWorkbench takes place along 2 parallel axes:
* <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.
* <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]]).

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.

Software Development Kit

2009-03-20T17:09:40Z

Keshav: /* Running the Plugin in geWorkbench */

Software Development Kit

2009-03-20T17:09:23Z

Keshav: /* Running the Plugin in geWorkbench */

Software Development Kit

2009-03-20T17:08:11Z

Keshav: /* Adding Source */

Software Development Kit

2009-03-20T17:06:35Z

Keshav: /* Adding Source */

Software Development Kit

2009-03-20T17:05:56Z

Keshav: /* Setting the Plugin Name */

Software Development Kit

2009-03-19T21:24:42Z

Keshav: /* Releasing the Plugin */

Software Development Kit

2009-03-19T21:15:43Z

Keshav: /* Running the Plugin in geWorkbench */

Software Development Kit

2009-03-19T20:36:16Z

Keshav: /* Download */

Software Development Kit

2009-03-19T20:34:40Z

Keshav: /* Adding Source */

Software Development Kit

2009-03-19T20:33:33Z

Keshav: /* Adding Source */

Software Development Kit

2009-03-19T20:32:55Z

Keshav: /* Adding Source */

Software Development Kit

2009-03-19T20:32:33Z

Keshav: /* Adding Source */

Software Development Kit

2009-03-19T20:31:12Z

Keshav: /* Adding Source */

Software Development Kit

2009-03-19T19:35:14Z

Keshav: /* Configure Plugin */

Software Development Kit

2009-03-19T19:35:02Z

Keshav: /* Configure Plugin */

Software Development Kit

2009-03-19T18:35:06Z

Keshav: /* Using the Development Kit */

Software Development Kit

2009-03-19T18:08:45Z

Keshav: /* Using the Development Kit */

Software Development Kit

2009-03-19T16:23:53Z

Keshav: /* Using the Development Kit */

Software Development Kit

2009-03-19T16:22:50Z

Keshav: /* Using the Development Kit */

Software Development Kit

2009-03-18T20:28:28Z

Keshav: /* Adding Source */

Software Development Kit

2009-03-18T20:28:08Z

Keshav: /* Adding Source */

User talk:Zhang

2008-10-09T18:22:31Z

Keshav:

User talk:Keshav

2006-01-31T01:50:44Z

Keshav: /* '''Building in Eclipse''' */

(Work in progress)

= '''Building in Eclipse''' =

Checkout geworkbench from adcvs.cu-genome.org/cvs/acallab. In exclipse this looks like :extssh:keshav@adcvs.cu-genome.org:/cvs/acallab
Add the following to the build path:

== Folders ==

geworkbench/_all
geworkbench/annotation
geworkbench/bin
geworkbench/src
geworkbench/conf

Add all src folders in the components directory to the build path. These are folders like:
geworkbench/components/alignment/src
geworkbench/components/analysis/src
geworkbench/components/annotations/src

Add all the jars in the lib directory.

Add all the jars in the respective components/lib directories to the build path.
Add all the jars in the plugins directory to the build path.

Right-click on the project and select properties. In the '''Order and Export''' tab make sure the jar mageom.jar is below mageom-client.jar. If you do not do this the eclipse compiler will use the incorrect version of the mage classes when building (it will use the mage classes that are not Identifiable ... ie. they do not have getIdentifier() or getName()). ''This issue is under investigation''.

When the application is run, the jars for each component are "added to the classpath" at runtime. Due to this, you should not have the jar files in component/xxx/lib or the jar files in the plugins directory on the classpath. <s>You can remove them from your run configuration or, alternatively, you can keep them on your classpath and run in '''dev''' mode. To do this, add the program argument -dev to your run configuration.</s> Actually, this doesn't seem to matter anymore.

== Ant Tasks ==

Running the ant tasks '''compile''' and '''run''' are a "test" to see if your edits have caused anything to break. When hacking, however, you should take advantage of your IDE and have it build your java classes automatically. This is what the setup above does for you.

= '''Magnet Development Process''' =

We need to consider us, the '''core developers''', as well as the '''component developers'''.

== '''Use Cases''' ==

== Core ==

'''Anonymous Access (eg. a component developer)'''

- can have read access to the core code, can modify locally, but does not have commit access. This is great for component developers that want to fix a bug or add a feature to test their component. They would then send the '''patch''' to us and we would apply/deny it. Eclipse has a great built-in patch system, allowing users to create a patch for our core and send it to use. IntelliJ probably has a good patch system as well. An example of a patch being sent to a core development team can be found here: http://www.mail-archive.com/andromda-devel@lists.sourceforge.net/msg06408.html.

To do this, we would just give users anonymous access to our repository. This could look like:

Host - magnet.columbia.edu
Repository Paths - (See "Repository paths", below)
User - anonymous
Password - (leave blank)
Connection Type - pserver

'''Committer Access (core developer and super users from the committee)'''

- can edit core and submit changes to our repository, and/or can commit to 'their' project (see Components below).

Host - magnet.columbia.edu
Repository Paths - (See "Repository paths", below)
User - (your committer user id, supplied by the webmaster)
Password - (your committer password)
Connection Type - extssh

Some component developers may be behind a firewall and are blocked from accessing hosts on port 20 (ssh) or port 2401 (pserver). We may want to consider a redirect host for those in this situation (on port 443). This could look something like:

Host - proxy.magnet.columbia.edu
Repository Paths - (See "Repository paths", below)
User - (your committer user id, supplied by the webmaster)
Password - (your committer password)
Connection Type - extssh

Use port 443 (if we support pserver we can also do this for pserver access on port 80)

===== Unix File Permissions =====

The core directory would have the following unix permissions:

drwxrws--- 2 cvsadmin gewcoreGrp /cvs/magnet/geWorkbenchCore

== Components ==

=== Closed Source Component ===

- users that are part of the grp responsible for the project can edit and submit changes.
- cvs access would look like:

Host - magnet.columbia.edu
Repository Paths - (See "Repository paths", below)
User - (your committer user id, supplied by the webmaster)
Password - (your committer password)
Connection Type - extssh

For example, componentA would have users part of the unix group gewcompAgrp, which has 'g+rwx' access to the componentA module. This would look like:

The core directory would have the following unix permissions:

drwxrws--- 2 cvsadmin gewcompAGrp /cvs/magnet/geWorkbenchComponents/componentA

- all other users would not have read access to this source code (this difference from open source component development). If those developing componentA would like to give access to a developer working on componentB, the componentB developer would be added to gewcompBGrp. For instance, before adding a developer from gewcompBGrp to gewcompAGrp, we would have:

ypcat group | grep gewcomp
''' gewcompAGrp::135:watkin '''
''' gewcompBGrp::136:keshav '''

After adding keshav to gewcompAGrp we would have:

''' gewcompAGrp::135:watkin,keshav '''

User keshav would now have rw privileges to componentA. Note that we cannot just give '''r''' privileges to keshav because the permissions set on componentA is '''g+rws'''. Setting componentA '''g+r''' is not an option using standard unix file permissions because you can only attach one access group to a file/directory. An alternative is to use '''AFS Access Control Lists (ACLs)''' which would allow us to give read permissions to individuals outside the component grp, but not allow them to write to the component directory ... while this is an option, I think it is safe to assume that if developers from grpA would like to disclose their source code to someone from grpB and the project is closed source, the reason is due to extenuating circumstances and they probably need the user from grpB to make a hack of some sort. Thus, more often than not you will need to give the grpB developer write access as well.

=== Open Source Component ===

- users that are part of the grp responsible for the project can edit and submit changes.
- cvs access:

Host - magnet.columbia.edu
Repository Paths - (See "Repository paths", below)
User - (your committer user id, supplied by the webmaster)
Password - (your committer password)
Connection Type - extssh

- all other users can checkout the project and view the source, make changes locally, and submit patches to the component development team.

Host - magnet.columbia.edu
Repository Paths - (See "Repository paths", below)
User - anonymous
Password - (blank)
Connection Type - extssh

The component directory would have the following unix permissions:

drwxrwsr-- 2 cvsadmin gewcompCGrp /cvs/magnet/geWorkbenchComponents/componentC

=== CVS Paths ===

Use the following repository paths to connect to the geWorkbench projects (this is how it is now ... it could change):
/cvs/magnet/geWorkbenchCore - The geWorkbench project (geWorkbench core project)
/cvs/magnet/geWorkbenchComponents - The Component project (multiple component projects developed by third party developers).
We will have to give users committer access to their specific project.
For example, the cvs root could be something like:

/cvs/magnet/geWorkbenchComponents/foobar

=== Bug Tracking/Issue Tracking ===

JIRA? - this is used by many large development teams.

See a jira example here: http://opensource2.atlassian.com/projects/spring/secure/Dashboard.jspa
You can sign in and check it out with: username=agroup, password=plink

== Release Management ==

We have to consider the core as well as the components (developed by others). Release managment is not to be confused with CVS versioning.

=== Proposal ===

==== Core ====

Core x.x.[x] -> [x]: bug removals
Core x.[x].x -> [x]: new minor features, deprecated APIs
Core [x].x.x -> [x]: new major features, cleaning APIs, no backward compatibility

==== Components ====

Components will have their own release cycle. We cannot force those who have already developed and released components to change their version numbers. We can, however provide a guide for new, interested developers. We could advise them to synchronize their major and minor versions with ours, giving them the flexibility to still have their own release management.

In our release managment we discuss releasing of the core. This should not be confused with what is downloaded by users. An archive that is downloaded should contain the core + supported components for that release (if a user downloaded just the core by itself it would not do anything).

User talk:Keshav

2006-01-31T01:50:24Z

Keshav: /* '''Building in Eclipse''' */

(Work in progress)

= '''Building in Eclipse''' =

Checkout geworkbench from adcvs.cu-genome.org/cvs/acallab. In exclipse this looks like :extssh:keshav@adcvs.cu-genome.org:/cvs/acallab
Add the following to the build path:
== Folders ==

geworkbench/_all
geworkbench/annotation
geworkbench/bin
geworkbench/src
geworkbench/conf

Add all src folders in the components directory to the build path. These are folders like:
geworkbench/components/alignment/src
geworkbench/components/analysis/src
geworkbench/components/annotations/src

Add all the jars in the lib directory.

Add all the jars in the respective components/lib directories to the build path.
Add all the jars in the plugins directory to the build path.

Right-click on the project and select properties. In the '''Order and Export''' tab make sure the jar mageom.jar is below mageom-client.jar. If you do not do this the eclipse compiler will use the incorrect version of the mage classes when building (it will use the mage classes that are not Identifiable ... ie. they do not have getIdentifier() or getName()). ''This issue is under investigation''.

When the application is run, the jars for each component are "added to the classpath" at runtime. Due to this, you should not have the jar files in component/xxx/lib or the jar files in the plugins directory on the classpath. <s>You can remove them from your run configuration or, alternatively, you can keep them on your classpath and run in '''dev''' mode. To do this, add the program argument -dev to your run configuration.</s> Actually, this doesn't seem to matter anymore.

== Ant Tasks ==

Running the ant tasks '''compile''' and '''run''' are a "test" to see if your edits have caused anything to break. When hacking, however, you should take advantage of your IDE and have it build your java classes automatically. This is what the setup above does for you.

= '''Magnet Development Process''' =

We need to consider us, the '''core developers''', as well as the '''component developers'''.

== '''Use Cases''' ==

== Core ==

'''Anonymous Access (eg. a component developer)'''

- can have read access to the core code, can modify locally, but does not have commit access. This is great for component developers that want to fix a bug or add a feature to test their component. They would then send the '''patch''' to us and we would apply/deny it. Eclipse has a great built-in patch system, allowing users to create a patch for our core and send it to use. IntelliJ probably has a good patch system as well. An example of a patch being sent to a core development team can be found here: http://www.mail-archive.com/andromda-devel@lists.sourceforge.net/msg06408.html.

To do this, we would just give users anonymous access to our repository. This could look like:

Host - magnet.columbia.edu
Repository Paths - (See "Repository paths", below)
User - anonymous
Password - (leave blank)
Connection Type - pserver

'''Committer Access (core developer and super users from the committee)'''

- can edit core and submit changes to our repository, and/or can commit to 'their' project (see Components below).

Host - magnet.columbia.edu
Repository Paths - (See "Repository paths", below)
User - (your committer user id, supplied by the webmaster)
Password - (your committer password)
Connection Type - extssh

Some component developers may be behind a firewall and are blocked from accessing hosts on port 20 (ssh) or port 2401 (pserver). We may want to consider a redirect host for those in this situation (on port 443). This could look something like:

Host - proxy.magnet.columbia.edu
Repository Paths - (See "Repository paths", below)
User - (your committer user id, supplied by the webmaster)
Password - (your committer password)
Connection Type - extssh

Use port 443 (if we support pserver we can also do this for pserver access on port 80)

===== Unix File Permissions =====

The core directory would have the following unix permissions:

drwxrws--- 2 cvsadmin gewcoreGrp /cvs/magnet/geWorkbenchCore

== Components ==

=== Closed Source Component ===

- users that are part of the grp responsible for the project can edit and submit changes.
- cvs access would look like:

Host - magnet.columbia.edu
Repository Paths - (See "Repository paths", below)
User - (your committer user id, supplied by the webmaster)
Password - (your committer password)
Connection Type - extssh

For example, componentA would have users part of the unix group gewcompAgrp, which has 'g+rwx' access to the componentA module. This would look like:

The core directory would have the following unix permissions:

drwxrws--- 2 cvsadmin gewcompAGrp /cvs/magnet/geWorkbenchComponents/componentA

- all other users would not have read access to this source code (this difference from open source component development). If those developing componentA would like to give access to a developer working on componentB, the componentB developer would be added to gewcompBGrp. For instance, before adding a developer from gewcompBGrp to gewcompAGrp, we would have:

ypcat group | grep gewcomp
''' gewcompAGrp::135:watkin '''
''' gewcompBGrp::136:keshav '''

After adding keshav to gewcompAGrp we would have:

''' gewcompAGrp::135:watkin,keshav '''

User keshav would now have rw privileges to componentA. Note that we cannot just give '''r''' privileges to keshav because the permissions set on componentA is '''g+rws'''. Setting componentA '''g+r''' is not an option using standard unix file permissions because you can only attach one access group to a file/directory. An alternative is to use '''AFS Access Control Lists (ACLs)''' which would allow us to give read permissions to individuals outside the component grp, but not allow them to write to the component directory ... while this is an option, I think it is safe to assume that if developers from grpA would like to disclose their source code to someone from grpB and the project is closed source, the reason is due to extenuating circumstances and they probably need the user from grpB to make a hack of some sort. Thus, more often than not you will need to give the grpB developer write access as well.

=== Open Source Component ===

- users that are part of the grp responsible for the project can edit and submit changes.
- cvs access:

Host - magnet.columbia.edu
Repository Paths - (See "Repository paths", below)
User - (your committer user id, supplied by the webmaster)
Password - (your committer password)
Connection Type - extssh

- all other users can checkout the project and view the source, make changes locally, and submit patches to the component development team.

Host - magnet.columbia.edu
Repository Paths - (See "Repository paths", below)
User - anonymous
Password - (blank)
Connection Type - extssh

The component directory would have the following unix permissions:

drwxrwsr-- 2 cvsadmin gewcompCGrp /cvs/magnet/geWorkbenchComponents/componentC

=== CVS Paths ===

Use the following repository paths to connect to the geWorkbench projects (this is how it is now ... it could change):
/cvs/magnet/geWorkbenchCore - The geWorkbench project (geWorkbench core project)
/cvs/magnet/geWorkbenchComponents - The Component project (multiple component projects developed by third party developers).
We will have to give users committer access to their specific project.
For example, the cvs root could be something like:

/cvs/magnet/geWorkbenchComponents/foobar

=== Bug Tracking/Issue Tracking ===

JIRA? - this is used by many large development teams.

See a jira example here: http://opensource2.atlassian.com/projects/spring/secure/Dashboard.jspa
You can sign in and check it out with: username=agroup, password=plink

== Release Management ==

We have to consider the core as well as the components (developed by others). Release managment is not to be confused with CVS versioning.

=== Proposal ===

==== Core ====

Core x.x.[x] -> [x]: bug removals
Core x.[x].x -> [x]: new minor features, deprecated APIs
Core [x].x.x -> [x]: new major features, cleaning APIs, no backward compatibility

==== Components ====

Components will have their own release cycle. We cannot force those who have already developed and released components to change their version numbers. We can, however provide a guide for new, interested developers. We could advise them to synchronize their major and minor versions with ours, giving them the flexibility to still have their own release management.

In our release managment we discuss releasing of the core. This should not be confused with what is downloaded by users. An archive that is downloaded should contain the core + supported components for that release (if a user downloaded just the core by itself it would not do anything).

Home

2006-01-26T19:53:28Z

Keshav:

'''geWorkbench''' is a Java-based open-source platform for integrated genomics. Using a component architecture it allows individually developed plug-ins to be configured into complex bioinformatic applications. At present there are more than 30 available plug-in [[components]] supporting the visualization and analysis of gene expression and sequence data. Many [http://caldev/workbench more components are scheduled for development] in the context of [http://magnet.c2b2.columbia.edu MAGNet], the National Center for Biomedical Computing hosted at Columbia University.

geWorkbench builds on [http://amdec-bioinfo.cu-genome.org/html/caWorkBench3.htm caWorkbench], a project funded by the [http://www.cancer.gov/ National Cancer Institute (NCI)] and the [http://www.amdec.org/ Academic Medical Development Company (AMDeC)]. Additional information about the history of this effort can be found [http://caldev/workbench here].

* '''[[Project Documentation|Documentation]]'''
** [[Tutorials]]
** [[Screenshots]]
** [[Project Reports]]
** [[Development Process]]
** [[Samples]]

* '''[[Download]]'''
** [[Releases]]
** [[Continuous Builds]]

* '''[[Components]]'''

* '''[[Community]]'''
** [[Mailing List]]

* '''[[Developers]]'''
** [[CVS Repository]]

MediaWiki:Sidebar

2006-01-26T19:52:16Z

Keshav: