Porting Core Plugins

Cytoscape's 2.6.x core plugins should now be largely ready for porting to 3.0. This is a list of the plugins to be ported and notes about doing so.

Basic Steps

1. You should begin with the code found in the cytoscape3 repository since all of the code has already been ported to maven.

2. Go into the directory containing the target module.

3. Try running mvn package on the module. You should see lots of errors!

4. Determine which bundles need to be declared in the module pom file. For instance if your module uses CyNetwork and CyNetworkView, you'll need to declare dependencies on org.cytoscape.model and org.cytoscape.view.model to get access to the necessary classes.

5. Now start the editing the code to fix the errors identified by the compiler (or your IDE). Keep fixing errors/compiling until everything compiles. See tips on porting to 3.0 for specific code suggestions.

6. Once everything compiles, you'll need to configure Spring to construct everything properly. See tips on porting to 3.0 for hints on how to get Spring working.

7. Now configure your osgi.bnd file to declare the proper packages public and private. In general, the expectation is that most coreplugin packages should be private. If you make anything public, then you should only be making a package that contains interfaces (and possibly an abstract class or two) public.

8. Now move to the top level cytoscape3 directory, uncomment your module from the top level pom and run mvn clean install to see if the whole project compiles.

9. Now verify that cytoscape runs by executing mvn pax:run. Iterate until it does!

Next Steps

• Once the modules are working within cytoscape3, we should move them to core3 so that they can exist as independent bundles.

• We should update the package names to omit . (period) characters. Instead we should use dashes. So, psi.mi should become psi-mi.

• If a package only contains implementation code and doesn't expose any public interfaces, the package name should include the -impl suffix. So, psi.mi, which doesn't expose any interfaces and only provides CyReaderFactory services, should probably be called psi-mi-impl.

attribute.browser

• Difficulty: medium to hard

• Lead developer: ???

• The challenge for this plugin will be change all the uses of CyAttributes to CyDataTable.

• Also, since there isn't one CyDataTable object (as it is in 2.6), we'll probably need to rework how tabs are created (i.e. one tab for every table?).

automatic.layout

• Difficulty: should be fairly easy

• Lead developer: ???

• This will primarily consist of porting from the old CyNetworkView to the new CyNetwork and CyNetworkView interfaces.

• Cleaning up the old Tunables won't be hard, but it will be a bit tedious to make sure all of the old ones are reflected in the new system.

biopax

• Difficulty: fairly easy

• Lead developer: ???

• This depends on the webservices API being present.
• Should be a private package which provides services.

cpath/cpath2

• Difficulty: medium (or trivial)

• Lead developer: ???

• First we should decide whether cpath should exist in 3.0 at all. In 2.x it seems that it only exists for legacy purposes. If this has been superseded by BioPax, then we should take this opportunity to retire cpath.

• If cpath should still exist:

  • We should combine cpath and cpath2 into a single bundle.
  • This depends on the webservices API being present.

filters/filters.old/quickfind

• Difficulty: medium

• Lead developer: ???

• We should refactor filters, filters.old, and quickfind. Since filters uses lots of quickfind widgets, we should work on a clean API for exposing these gui elements.
• We should also provide a general filters API that can be used in a non-gui context.
• We should coordinate this API with Maital on her data mining API.

editor

• Difficulty: hard

• Lead developer: AllanKuchinsky

• The trick here will be integrating cleanly with the presentation.
• We still need to fire events for node clicks, right clicks, etc..

linkout

• Difficulty: fairly easy

• Lead developer: ???

• We should consider exposing a linkout API so that plugin writers can easily add their own links.
• Linkout itself should become a Task/TaskFactory that is registered as a service and then gets added to the proper context menus.
• We still need to get the context menu mechanism working again.

manual.layout

• Difficulty: easy to medium

• Lead developer: ???

• The only real difficulty will be figuring out how manual layout's internal data structures work with CyNetworks.

• The math.xform code should be included in this package and hidden since this is the only package where it's used.

merge

• Difficulty: medium

• Lead developer: ???

• The existing merge code depends a great deal on 2.6.x RootNetwork, which means almost all of the existing code will go away.

• The code from last year's Google Summer of Code should probably replace this, since that code merges based on attributes. That code will just need to be ported.
• Some of the existing merge code might be of use when we're talking about merging nodes in subnetworks.

ontology

• Difficulty: fairly easy???

• Lead developer: ???

• This is just a special case of table import, which implies that either table import needs a public API or that this code should be included in the table import bundle and hidden.

psi.mi

• Difficulty: easy

• Lead developer: ???

• This should only be a matter of changing from the old interfaces to the new and registering new IO services.

sbml.reader

• Difficulty: easy

• Lead developer: ???

• This should only be a matter of changing from the old interfaces to the new and registering new IO services.

table.import

• Difficulty: easy to medium

• Lead developer: ???

• This should primarily just be a matter of updating API calls to work with new interfaces.
• We'll need to decide whether an interface should be exposed for ontology or whether ontology should be included in this bundle.