Skip to content

Improvements to PlantUML install instructions

John Gaughan requested to merge jgaughan-master-patch-51726 into master

What does this MR do?

I just finished helping a user (see this ZD ticket - internal only) get set up with the PlantUML integrations, and noticed multiple things that were outdated, inaccurate, or missing in the Debian/Ubuntu installation instructions. This MR corrects those items.

Using the official PlantUML package rather than Maven

This MR includes a change from cloning the PlantUML Git repository and packaging it with Maven, to installing the latest release from PlantUML directly.

The instructions to self-package PlantUML with Maven come from the November 2016 commit which added the PlantUML integration to GitLab. This made sense at the time, because PlantUML didn't start using tags until 2017, and their oldest packaged release is dated October 2019.

The official release seems to work a bit better than the self-packaged solution. We tested out both of them in Debian/Ubuntu:

Environment

  • Ubuntu: 20.04.6 LTS
  • GitLab: 16.0.4
  • JDK: 11.0.19
  • Apache Maven: 3.6.3
  • Tomcat: 10.1.9
  • PlantUML release: v1.2023.8

Test: run curl -Lv http://localhost:8005/plantuml/

Package solution PlantUML integration is working http response
self-packaged No 503
self-packaged Yes 503
PlantUML release No 503
PlantUML release Yes 200

Note that when using the self-packaged version, the curl returned a 503 even when the PlantUML server was working.

Related issues

Author's checklist

If you are a GitLab team member and only adding documentation, do not add any of the following labels:

  • ~"frontend"
  • ~"backend"
  • ~"type::bug"
  • ~"database"

These labels cause the MR to be added to code verification QA issues.

Reviewer's checklist

Documentation-related MRs should be reviewed by a Technical Writer for a non-blocking review, based on Documentation Guidelines and the Style Guide.

If you aren't sure which tech writer to ask, use roulette or ask in the #docs Slack channel.

  • If the content requires it, ensure the information is reviewed by a subject matter expert.
  • Technical writer review items:
    • Ensure docs metadata is present and up-to-date.
    • Ensure the appropriate labels are added to this MR.
    • Ensure a release milestone is set.
    • If relevant to this MR, ensure content topic type principles are in use, including:
      • The headings should be something you'd do a Google search for. Instead of Default behavior, say something like Default behavior when you close an issue.
      • The headings (other than the page title) should be active. Instead of Configuring GDK, say something like Configure GDK.
      • Any task steps should be written as a numbered list.
      • If the content still needs to be edited for topic types, you can create a follow-up issue with the docs-technical-debt label.
  • Review by assigned maintainer, who can always request/require the reviews above. Maintainer's review can occur before or after a technical writer review.
Edited by John Gaughan

Merge request reports