Replace Graphviz/DOT with a Java implementation

[labkey-adam]

Rationale

A native Java implementation is much simpler and cleaner than shelling out to an executable. Switching to https://github.com/jamisonjiang/graph-support

Related Pull Requests

• Replace Graphviz/DOT with a Java implementation server#1328

Tasks

• Dev
• Code Review
• Manual Testing - @labkey-jeckels
  • Pipeline diagrams: Admin Console -> Pipelines and Tasks -> clicking some of the pipelines and tasks will show a diagram
  • Group diagrams: go to any permissions page, for example, Site Permissions -> click the Group Diagrams tab
  • Module dependency diagrams require a code change: uncomment the graphModuleDependencies(dependencies, "all") line in ModuleDependencySorter.java (line 84) and compile. Start up the server and examine the file in the temp directory that gets logged.
  • Experiment diagrams. Easily accessed from flow, MS2, and other assays. You'll notice that I'm rendering the new diagrams somewhat larger than the old ones, but monitors are much higher resolution now vs. when we chose the old image-based implementation scaling factor. Current scale factor is arbitrary; we can easily scale it up or down, if desired.
  • Note that pipeline and experiment diagrams currently render both old and new versions for comparison purposes during testing. I plan to remove the old versions before merge.
• Report minor discrepancies to graph-support project. 1) No support for \L and \R for text alignment. 2) Large margins even when specifying margin="0,0". 3) No support for transparent background.
• Needs Automation?? I don't think so
• TeamCity Review and Merge
• Stop copying executables in the build and distributions
• Stop installing executables (graphviz) during deployment
• User education handoff

User Education

• Add a release note bullet that graphviz is no longer used and can be uninstalled
• Remove any installation/configuration docs that reference graphviz

[labkey-jeckels]

Claude is concerned about units that aren't two characters.

Issue: The method assumes units are always exactly 2 characters (value.substring(value.length() - 2)). It uses StringUtils.isNumeric(units) to detect "no units". If the last two characters are numeric, units = null (no units). But this fails for values with 1-char units (e.g., "m" or future SVG units), or values where the last character is a digit and second-to-last is a unit letter (e.g., "785pt" with trailing numeric in the number). It also silently uses units for numeric-only 2-char endings. In practice the current SVG output always uses pt or px, so this works today, but the 2-char assumption is fragile.

Why it matters: If graph-support ever outputs different units, parsing would silently fail or corrupt the parsed value.

Suggestion: Use a more robust regex-based approach (e.g., match trailing alpha chars) to separate numeric value from units.

[labkey-jeckels]

Claude is concerned about assumptions about a trailing space here:

Issue: When size == null (removing the attribute), the code does svg.substring(0, idx) + svg.substring(end + 2). Here end is the position of the closing ". end + 1 is the " itself, so end + 2 skips one character past the closing quote — this is intended to remove the trailing space. But if the attribute is at the end of the tag or is followed by something other than a space, this silently removes an extra character.

Why it matters: Could corrupt the SVG string if attribute is not followed by a space (e.g., the attribute is the last before >).

Suggestion: Check that svg.charAt(end + 1) == ' ' before skipping it, or use a regex replacement.

[labkey-jeckels]

Error handling for the runtime exceptions thrown here?

[labkey-jeckels]

Initial testing pass looks OK. Biggest discrepancy is that the new output is significantly taller than the old. That's especially noticeable on the hexagons (which seems fine), but there's also quite a bit more empty space above and below the graph. Maybe that's what you called out in terms of margins.