Cytoscape's core build is a script that clones 26 repositories

This repository is the assembly line, not the application

The first line of the README sets the expectation. This is the primary Maven project for building the Cytoscape Desktop application, and the project description calls Cytoscape an open source platform for network analysis and visualization. The distinction matters because what lives here is a top level pom file and a utility script, with the note that Cytoscape core has multiple repositories for managing its code. The README is explicit about who should be reading: this document is a guide for developers who want to build the entire Cytoscape core distribution from scratch, and most app developers will not need to clone this repository. If you are writing an app against Cytoscape rather than editing it, the guide it points to instead is the Cytoscape Developer Documents. The bug report form is at cytoscape.org, and the same applies to the other Cytoscape Desktop sub-projects.

JDK 17, Maven 3, Git and a path with no blanks in it

The requirements list is short and the first item is unusual. You need a computer with Windows, Mac or Linux, JDK 17, Maven 3, Git, the cy.sh utility script that is available in this repository, and a working directory whose path contains no blanks. The blank path rule gets its own section, and the reasoning is precise. cy.sh refuses to run when the current path contains a space or a tab, and it says so before it clones or builds anything. Every cy.sh command itself works fine from such a path; the problem is the launcher the build produces, gui-distribution/assembly/target/cytoscape/cytoscape.sh, which does not quote its own path and so cannot start from a directory with a blank in it. That launcher comes from the cytoscape-gui-distribution repository, so the fix belongs there. The stated reason for the early check is that you find out immediately rather than after cloning 26 repositories and building 122 modules into a tree that will not start.

One JDK for everything, with a table saying which command needs it

The JDK question is settled by a table rather than an argument. JDK 17 builds everything, both the build and the build-apps commands run on it, and you do not need a second JDK installed or to switch JAVA_HOME between them. The table then breaks down the commands by requirement. The pull, pull-apps, switch, switch-apps, branch, branch-apps, status, push and reset commands need any JDK, because they only run git and no Java is involved. The core build needs 17 or newer, because the parent pom compiles with a release setting of 17 that Maven cannot honour on an older JDK, and it was verified on JDK 17. The core apps need 17, since the apps compile for Java 11 and every app that reaches the compile step does so successfully on JDK 17, with the remaining failures caused by something else. On a Mac, /usr/libexec/java_home -V lists the installed JDKs and JAVA_HOME=$(/usr/libexec/java_home -v 17) selects one.

build-apps runs, prints a summary, and exits non-zero

The build-apps command is the one that tells you the truth about the current state of the tree. It attempts every core app, prints a summary of what built and what did not, and exits non-zero if anything failed. From a fresh checkout of this tree, 5 of the 20 apps currently build cleanly. The failures sit in the apps own repositories rather than in cy.sh, which is confirmed by the fact that a plain mvn clean install inside an app directory fails in exactly the same way. That distinction is the useful part of the design, because it tells you where to look. An IDE is fine for maintaining Cytoscape 3, and Eclipse is described as a popular choice with its own Maven and Git support, but the README recommends following the command line procedure for the initial clones and builds and switching to an IDE afterwards.

Nine apps fail on an old bndlib, and the fix belongs upstream

The first of the two failure causes is specific and well diagnosed. Nine apps are pinned to maven-bundle-plugin 4.1.0: amatreader, analyzer, biopax, core-apps-meta, cyREST, json, idmapper, webservice-biomart-client and copycat-layout. That plugin embeds bndlib 4.1.0, whose putResource method structurally modifies a TreeMap from inside that same map's computeIfAbsent mapping function, and TreeMap detects the reentrant modification and throws ConcurrentModificationException. The README is emphatic that this is a bug in bnd and not a JDK incompatibility, so no JDK version avoids it, and later plugin releases ship a fixed bndlib while the core itself uses 5.1.2 and builds without trouble. The fix belongs in each app own repository, by raising that app's maven-bundle-plugin.version to a release carrying a fixed bndlib. The reason cy.sh deliberately does not override it is that the plugin generates the OSGi manifest, and forcing a version from the outside would make it produce bundles that differ from the ones the app repositories release, silently and for every app at once.

Validating the plugin bump before you touch the POM

There is a concrete command for confirming the newer plugin resolves the failure, and the README asks you to run it before you commit anything. You go into the app directory and pass the plugin version on the command line, skipping the tests, which is enough to see whether the bundle plugin resolves:

cd apps/<app> && mvn clean install -DskipTests -Dmaven-bundle-plugin.version=5.1.9

The instruction that follows matters as much as the command. Use that to validate the fix, then commit the version bump in the app repository, and not as a standing workaround for building the tree. The distinction is between fixing a specific app and changing the build so that every app gets a different bundler than the one its own maintainers chose.

Six apps fail because their dependencies are gone

The second failure class cannot be fixed with a plugin version, and the README says so directly. Six apps have dependencies that no longer resolve: opencl-layout, psi-mi, sbml, diffusion, webservice-psicquic-client and file-transfer-app. The reasons differ per app. opencl-layout wants core API jars at 3.10.0-SNAPSHOT and diffusion wants 3.9.1, while the tree builds 3.11.0-SNAPSHOT. sbml wants an unpublished third-party snapshot, jsbml 1.6.1-SNAPSHOT. webservice-psicquic-client wants a dependency from the retired SpringSource repository, psi-mi wants a parent POM absent from its own repository, and file-transfer-app wants a test-jar that was never published. Overriding the bundle plugin does not help here, because these need attention in their own repositories. That is a real dependency-rot problem, and it is the kind that a single build script cannot paper over.

Build scripts live elsewhere, and some features are web services

Two loose ends from the README are worth noting for anyone planning the work. The first is that all build scripts are moved to a separate repository, Cytoscape Admin Scripts, so the operational tooling is not in this tree even though the cy.sh launcher is. The second is that some Cytoscape functions rely on code deployed as services available on web servers, and the README notes that such services are generally callable by Cytoscape or directly by non-Cytoscape clients such as Python. That is a deployment dependency outside the desktop application, and it is worth knowing before you assume the core build is self-contained. The repository itself is small in what it contains: a .gitignore, an .mvn directory, .travis.settings.xml, .travis.yml, CODE_OF_CONDUCT.md, CONTRIBUTING.md, the README, cy.sh and pom.xml, with the default branch on develop and the primary language listed as Shell because the launcher script dominates the file count.

Editorial conclusion

Cytoscape's core repository suits a developer who intends to build the whole Cytoscape 3.10 desktop distribution, or to work on the core itself, and who is prepared to clone 26 repositories and compile 122 modules. It does not suit an app developer, since the README says most app developers will not need to clone it, and it does not suit anyone hoping for a clean build today, because only 5 of the 20 core apps build cleanly from a fresh checkout. Before starting, read the JDK table and confirm you have JDK 17, clone into a path with no spaces or tabs because cy.sh refuses to run otherwise, and note that the last push to the repository was on 2026-10-09 with release 3.10.5 dated 2026-09-29.

Frequently asked questions

Official sources

1. cytoscape/cytoscape on GitHub
2. Issues
3. Project website
4. README
5. Releases