pluginProcess

Please Note: This page is not meant for plugin developers. To develop and submit a plugin please see the plugin tutorial.

Agenda

1. Plugin Website

• Developer View/Website:
  • developer submit plugin to website (jar (source if possible), documentation, contact info)
  • services provided: build system, source control, new release support
  • cytoscape certified plugins vs other plugins (more stringent requirements for certification)
    • what does certified mean ?
      • compiles, documentation, some kind of unit test
  • Open Issues:
    • where does this website live, how it operates
    • do we want to require source code submission - should not be mandatory
• User View/Website (would be nice, but not currently needed):
  • common location for plugins
  • organized
  • sorting/query (most popular)
  • download tracking
  • advertising
  • community
  • reduce redundancy

2. Automated Import into Cytoscape (2.5 goal)

• Issues:
  • users have hard time managing/loading plugins
  • advertising - knowing what is available (funding)
  • knowing what core code is used by plugins
• What are requirements to show up on the certified list ?
  • when user submits plugin, notifies core team what version of cytoscape it has been tested on
  • core team member runs plugin on particular version of cytoscape to make sure plugin does not break core
  • if bug appears, notify user, give them some time, say one week to fix or it gets removed

3. Plugin dependencies

• plugins do not depend on each other (exception for core plugins)
• plugins communicate via attributes
• layout broker, import broker, and others as needed
• library issues:
  • we dont want jars in plugins directory that are not plugins
  • core team maintains libraries in plugin/libsdirectory