Update jetty and tomcat to latest version

[HeinrichAD]

This PR ...

• ... updates jetty 9.4 to 11.0.7
• ... updates tomcat 9.0 to 10
• ... is one part of #189

Important changes which may need further discussion

• Java 11 Since jetty 10 the java 8 support ended. Only java 11+ is supported. Source: https://www.eclipse.org/jetty Tomcat currently supports java 8. But, with the next version (10.1.0), java 11+ is also required. Source: http://tomcat.apache.org/whichversion.html BUT: Since in principle the code itself is mostly java 8 capable, it is possible with reasonable effort to build at least the plantuml.war file with Java 8 as taget. (Only plantuml.war file, no jetty or tomcat realated things, no tests. Also see diff pom.xml and pom.jdk8.xml) For this reason I have added the java 8 war file to the release in addition to the java 11 ones.
• war generation Different war files are needed for jetty and tomcat. The reason is that jetty has apache-jsp artifact already on its classpath and does not start if the war file includes it. Tomcat on the other hand requires it. Hence: There is now a plantuml-VERSION.war and plantuml-jsp-VERSION.war.
• use plain scriptlets The advantage is that this removes http://java.sun.com/jsp/jstl/core and its dependencies. Normally, this could be interpreted as a step backwards. However, since the scriptlets are only used once and thus many old dependencies could be removed, this step is worthwhile. Furthermore, jetty 11 does not provide its support out of the box like jetty 9.

Additional changes

• add image map of the diagram in HTML format if the image has some position information
• run tests against all possible servers (embedded jetty, mvn jetty:run, jetty-runner, jetty docker image, tomcat docker image, java 8 builded plantuml.war file)
• fix duplicate classes and resources in classpaths
• jetty.port flag is deprecated use jetty.http.port
• add note to readme that jetty-runner is deprecated
• remove "Welcome" servlet which was never used

[stevehipwell]

@HeinrichAD this PR has broken the Docker release action and we're now only getting generic tags. I suspect that it's due to the change in trigger in the new docker.yaml file breaking the release actions.

FYI @arnaudroques

[HeinrichAD]

I'm sorry to hear that. Unfortunately, my PC died today. Currently, I'm doing everything from my phone. I will need to bye a new one tomorrow und set it up. I'm sure that I will not be able to do much until next week.

But. The Action shows no error and hub.docker.com has the new images. Furthermore, I only export this workflow part into a own file and did not change the workflow (if I remember correctly).

Edit: I see. There is no tag with the new plantuml version on docker hub.

[stevehipwell]

@HeinrichAD you moved the Docker code into a workflow with a different trigger and it's a common pattern for an action to have different functionality based on the workflow trigger. I'm not sure why you moved the actions in the first place?

[HeinrichAD]

A workflow should not do everything. The main workflow creates all sources files and uploads them as release. The docker workflow is responsible for the docker related stuff. Troubleshooting is also simplified. Moreover, the former should not fail if the latter does not work.

Problem: workflow/docker.yml If I'm correct, the problem is that due to the changed trigger (workflow_run) the variable {{raw}} is not set correctly.

I see multiple solutions:

• use own variable with type raw instead of {{raw}} with type semver
• change the trigger (same as main.yml, disadvantage: docker is also released if main workflow and releases fail)
• move back and do everything in main.yml (merge docker and main workflow)

Each solution has its own advantages and disadvantages.

For the first idea you could use https://github.com/marketplace/actions/get-latest-tag to get the tag value and change e.g.: type=semver,pattern=jetty-{{raw}} to type=raw,value=jetty-{{steps.previoustag.outputs.tag}} (or what you name your variable)

@stevehipwell @arnaudroques I'm sorry but I can fix and test it at the moment by myself.

[stevehipwell]

@HeinrichAD I don't think that you have understood how GitHub actions are intended to be composed, specifically the workflow vs job part. A workflow is for a single group of related steps and can be further broken down into multiple jobs if required. It's a shame you didn't loop me in to your changes, as the last person to commit to the main workflow, as that would have saved this breaking.

Moving forward I suggest that you open a PR to reinstate the Docker actions back to the job in the main workflow. Once this is merged you can open a PR to split the Docker steps out into a separate job in the same workflow, which will allow the build to pass even if the Docker part fails. Just remember that each additional job (or workflow) increases both the cost (more VMs) and time (more setup and moving of artifacts) of the CI process.

[arnaudroques]

@HeinrichAD Take the time you need to set up your PC

@stevehipwell I am really far from my area of expertise here. I suggest that you and @HeinrichAD discuss together to see how to fix this. As last option, I can revert this PR but I think it would be a shame because there are interesting improvement in this PR. What do you think about it ?