feat: html output, web front end

[ed-g]

Summary:

Features

• Create an html report in the same folder as the json report when run via command line.
• Add an embedded web server which can be run via a --web_server option.

Build

• Use spotless to check java syntax instead of com.github.sherter.google-java-format which appears to be unmaintained.
• Fix various small gradle warnings.
• Added a build.gradle task to compile js libraries, and bundle web front end assets to java source code.

Expected behavior:

• Command line validation writes a report.html file in the output directory, the file name can be chosen by --validation_html_report_name.

• --web_server will run an embedded web server on port 6888, where one can submit GTFS files for validation.

• ./gradlew generateViewerAssets will re-generate ViewerAssets.java based on source html, js, and css. There might be better ways to achieve this, I'm not very familiar with best practices for java bundling or code generation. UPDATE: I've added a dependency from build to the js compilation and bundling steps. I think this is how gradle is supposed to work but I'd love a review from someone who is knowledgeable. See main/build.gradle.

Please make sure these boxes are checked before submitting your pull request - thanks!

• Run the unit tests with gradle test to make sure you didn't break anything
• Format the title like "feat: [new feature short description]". Title must follow the Conventional Commit Specification(https://www.conventionalcommits.org/en/v1.0.0/).
• Linked all relevant issues

#495

• Include screenshot(s) showing how this pull request works and fixes the issue(s)

[ehowington]

a much needed feature to expand access to the validator beyond consuming software applications! Producers have relied on the quite stale feedvalidator.py script from the transitfeeds library of scripts and not having a human-readable out for this validator has hindered adoption.

[isabelle-dr]

Hello, thank you so much for this contribution @ed-g!
This is indeed one of the top requested features for this tool :)

One question: what is the reason you chose Spark Java?
Not sure if you were aware, we previously started to work on an Interface using Spring Boot (in PR#421).

[ed-g]

Hello @isabelle-dr! You're very welcome :-)

My coworker and I took a look for the previous web ui, based on this comment, #445 (comment) and #495 (comment) we got the sense that 2.0 updates may have changed some internals that it relied upon?

There is no particular reason why I chose spark java over spring boot or another web framework. I think it could be ported to pretty much anything if the team has another preference.

[ed-g]

I've added some basic Jasmine tests and merged report text and css updates.

Our current project funding ends today, please don't be shy if you have any quick requests for improvements.

[themightychris]

Would it be trivial to check here if an Accept: application/json and respond with the JSON instead of an HTML render? This would make it trivial to run the already-published docker container as a web service on a cluster that separately maintained and deployed static web UIs or other services could leverage.

I'm kind of looking for the inverse of #1119—a way to run the validator as a persistent web service one could POST GTFS to and get back the JSON without any user interface being served by the validator itself. Of course sensitivity to an Accept request handler seems like a trivial way this PR could do both.

[ed-g]

I'm only superficially familiar with Spark, but it looks like the https://sparkjava.com/documentation#request object will provide the Accept header, but it would still be necessary to parse the list of media types along with their quality factors.

That sort of thing is not built into Spark but a template engine (they support multiple: https://sparkjava.com/documentation.html#views-and-templates) might provide that feature.

It might be easier to simply add a post handler for /validate/report.json which always returns JSON from the form submission.

That said: this web server is meant as a proof of concept, from what I understand per #1112 the future web UI will likely be written in Spring based on work in #421. So any JSON feature may need to be rewritten against that framework once it's ready.

[themightychris]

Can anyone share a brief snapshot on where this is on getting merged? Are there blockers?

[isabelle-dr]

Closing this PR, since this will not be worked on further