## page was renamed from Cytoscape_3.0/PortingCorePlugins
= 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 coreplugin code found in the [[http://chianti.ucsd.edu/svn/cytoscape3/trunk|cytoscape3]] repository since all of the code has already been ported to maven.
 1. Go into the directory containing the target module.
 1. Try running '''mvn package''' on the module.  You should see lots of errors!
 1. 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.
 1. 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 [[TipsOnPortingTo3.0|tips on porting to 3.0]] for specific code suggestions.
 1. Once everything compiles, you'll need to configure Spring to construct everything properly.  See [[TipsOnPortingTo3.0|tips on porting to 3.0]] for hints on how to get Spring working.
 1. 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.
 1. 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.
 1. 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?).

=== 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:'' MaitalAshkenazi, PengLiangWang
 * GSoC project [[http://socrates2.cgl.ucsf.edu/GenMAPP/wiki/Google_Summer_of_Code_2009/Srinivas|Integrated Data Mining bundle]] by Srinivasarao Vundavalli.
 * 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.