geWorkbench

(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. 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. 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

Anonymous Access (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.

This is standard practice.

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.

  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

CVS Paths

Use the following repository paths to connect to the geWorkbench projects (this is how it is now ... it could change):

  /cvs/geworkbench - The geWorkbench project (geWorkbench core project)
  /cvs/components - The Component project (multiple component projects developed by third party developers).  We will have to give users committer access to their specific project.