CorePluginsAndLibraries

Core Plugins and Libraries

Problem

Cytoscape core plugins and libraries are currently maintained in the csplugins CVS project and other locations. The problem is that the core plugins and libraries represent only a small fraction of the code in the csplugins project. As a consequence, it is difficult for developers to find the source code for the core code which impedes their ability to fix problems.

Definitions

• Core Plugin - A jar file that provides a service to Cytoscape through Cytoscape's plugin mechanism. While core plugins provide important features, nothing in the Cytoscape project depends on their existence to compile or run (however, without the core plugins, certain functionality will not exist). Core plugin jar files reside, from Cytoscape's perspective, in the cytoscape/plugins/core directory.

  • Current core plugins:
    • browser.jar
    • control.jar
    • cpath.jar

    • CytoscapeEditor.jar

    • data-aux.jar
    • exesto.jar
    • filter.jar

    • HierarchicalLayout.jar

    • yeast-context.jar
    • yLayouts.jar

• Core Library - A jar file required to compile and run the cytoscape project that we control. Code in the cytoscape project makes method calls to classes in the library. Core library files reside, from Cytoscape's perspective, in the cytoscape/lib directory.

  • Current core libraries (that we control):
    • com-nerius-math-xform.jar
    • cytoscape-cruft-obo.jar
    • cytoscape-graph-dynamic.jar
    • cytoscape-graph-fixed.jar
    • cytoscape-graph-layout.jar
    • cytoscape-graph-legacy.jar
    • cytoscape-task.jar
    • cytoscape-util-intr.jar
    • fing.jar
  • Core libraries that we control but are external of our CVS system.
    • giny.jar
    • phoebe.jar

Proposed Solution

• Create a new cvs project that will contain the source for each core plugin.
• Create a new cvs project that will contain the source for each core library.
• Each project will have its own directory to keep the code as separate as possible from other plugins (reducing interdependencies).

Questions

1. Should there be a master build file at the top of each project that recurses into each subdirectory and builds all of the projects? This would help with things like nightly builds, etc. but could also lead to interdependencies between plugins.
2. Should we remove the core code from csplugins or should we risk having duplicate projects?
   • This depends on our ability to move the CVS history of the code. Since this is known to be a challenge, perhaps we could provide pointers to the respective projects and "disable" the old projects by adding a warning target to the build files?
   • Or we could just nuke the history, which is probably not a great idea.
3. Should we move GINY?