Core Plugins and Libraries


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.


Proposed Solution


  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)

CorePluginsAndLibraries (last edited 2009-02-12 01:03:27 by localhost)

Funding for Cytoscape is provided by a federal grant from the U.S. National Institute of General Medical Sciences (NIGMS) of the Na tional Institutes of Health (NIH) under award number GM070743-01. Corporate funding is provided through a contract from Unilever PLC.

MoinMoin Appliance - Powered by TurnKey Linux