Revision as of 23:47, 23 January 2006

(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

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/component/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/component/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).