As described in another thread (#4631 (comment)), Maven Central is used in the builds to fetch a version of the Antlr Tool .jar. The problem is that on a heavily loaded Maven Central, the server will deny download requests when heavily loaded, even though the GitHub Actions VM servers are not.
Additionally, the 'antlr4' tool used doesn't perform retries; if it fails once, the request is never attempted again.
https://github.com/antlr/antlr4-tools/blob/dd4ea2883ddcfe023c8ffc3b7f96289bef9ef0c9/antlr4_tool_runner.py#L54-L69
I have a modification of antlr4-tools that fixes these problems. See https://github.com/kaby76/antlr4-tools/tree/tools-fix-fetches. However, the change hardwires the .py to run the command-line tool rather than the GUI. To call, runpython3 antlr4_tool_runner.py; there won't be a published version in PyPl because I don't understand Python at all.
As described in another thread (#4631 (comment)), Maven Central is used in the builds to fetch a version of the Antlr Tool .jar. The problem is that on a heavily loaded Maven Central, the server will deny download requests when heavily loaded, even though the GitHub Actions VM servers are not.
Additionally, the 'antlr4' tool used doesn't perform retries; if it fails once, the request is never attempted again.
https://github.com/antlr/antlr4-tools/blob/dd4ea2883ddcfe023c8ffc3b7f96289bef9ef0c9/antlr4_tool_runner.py#L54-L69
I have a modification of antlr4-tools that fixes these problems. See https://github.com/kaby76/antlr4-tools/tree/tools-fix-fetches. However, the change hardwires the .py to run the command-line tool rather than the GUI. To call, run
python3 antlr4_tool_runner.py; there won't be a published version in PyPl because I don't understand Python at all.