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 - (move into the core and remove the old browser code)

    • control.jar - (subsume into our new ManualLayout.jar - Will include Align and Rotate/Scale menu options)

    • cpath.jar

    • CytoscapeEditor.jar

    • data-aux.jar - (should be library instead?)
    • exesto.jar - (should be library instead?)
    • filter.jar

    • HierarchicalLayout.jar - (subsume into our new AutomaticLayout.jar)

    • yeast-context.jar - (A yeast "skin" for cytoscape)
    • yLayouts.jar
  • Core Plugin Guidelines:
    • Independent of other plugins.
    • Cytoscape core is independent of the plugin.
    • Minimal functional unit.
    • Conceptual integrity - Plugins should appropriately cluster functionality, that is maximize between plugin variance and minimize within plugin variance.
    • No biological semantics.

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

   • COMMENT from GaryBader: From the Cytoscape developer point of view, it would be easier to have a target in the cytoscape build file that collected code from various directories (even outside of /cytoscape) that would depend on certain other directories being present. If you wanted to automate the full build, including core libraries and core plugins, then you would only need the cytoscape build file and you would just have to check out the required directories. Normally, users would not need to automate this type of full build, but it would be useful for the build system, since it would extend our regression testing to all our code, not just the cytoscape subset. (This comment is based on my assumption that one build file is easier to deal with than many, but ant may have nice features I'm not aware of that deal with this situation nicely).

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.

     • COMMENT from GaryBader: I think we decided at the hackathon to keep the old code in csplugins and provide a notice (e.g. a readme file or build warning message) that lets developers know where the project moved to. We decided it was not a good idea to move the CVS history because the history may depend on files being in specific places and in this case if a user checked out an old version, it would not be able to compile. Also, I think we said it would be good to have a notice in the new directory pointing to the old directory (as a readme file e.g. version-note.txt or some other standardized mechanism).

3. Should we move GINY?

   • COMMENT from GaryBader: I think it would be useful to move giny in its own directory in the Cytoscape CVS server and putting a note on the sourceforge site that this has moved. We need to ask Rowan what he thinks, though. The original motivation for putting it on sourceforge was that it would be useful outside of Cytoscape and that would be an easier place for people to find it and contribute. However, no one is taking care of the project now, the separation has caused an old version of giny to be on the sourceforge site (leading to people I know who did not know about the FING implementation to evaluate and reject the old version)