For unfortunate reasons, we have to add a separate (build-time) dependency on
proguard-core, code from which proguard-base relies on but neither includes
directly nor expresses as a dependency.
How is it in the year of our lord two thousand and twenty two, we are still
making such basic build errors in our Maven plugins and POM files?
Nashorn was removed in JDK15, but the PAC proxy detection code depends on
having a JavaScript VM (what a twisty maze of passages). Rather than remove it
completely, I'll just keep the tests working so that people who use Getdown
with PAC proxies on JDK 14 or earlier can keep on trucking.
Perhaps the JavaScript code could be rewritten in Java and this weird massive
dependency could be eliminated?
It is possible to use versioned mode without patch files, though there's no way
to specifically tell Getdown whether or not you are using patch files, so it
always tries to download them. If they don't exist, it should now log one
reasonable warning and then proceed to update based on resource hashes.
When set, it disables stdout/stderr redirection and uses java.exe on Windows so
that a console window is shown with output from the launched app.
This removes the use of a debug.txt file.
This revamps the way proxy handling is done to allow us to just proceed as
normal, and then if we get HTTP errors that indicate that we need a proxy or
need proxy credentials, we ask for them and then retry everything.
We still try to auto-detect the need for a proxy on our very first invocation
because on the first invocation, a failure to fetch a URL may well indicate
that a proxy is needed, but that same assumption does not hold on subsequent
invocations. In those later cases, it's probably just a transient network
failure and it would be weird and annoying to pop up the "please provide proxy
config" dialog in those cases.
Thanks pb00068 for getting this ball rolling, even though once again I have
nearly entirely rewritten the PR. I need to kick that habit. :)
What a horrible wart lingering from the early days of the Internet. Note to
future designers: please do not express configuration using a Turing complete
language.
Thanks jenriq for getting the ball rolling on this.
Closes#196.
This makes it *way* easier to view and edit the translation files and avoids
the danger of accidentally slipping UTF-8 encoded characters into existing
files during editing.
Michael Bayne