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.
Maven is not using the 1.6 version of the GPG plugin for some reason, even
though the place where the plugin is triggered explicitly specified that
version. Maybe this new set of chicken sacrifices will cause Maven to do the
right thing.
For some incomprehensible reason, Maven is not using the config for
maven-javadoc-plugin when I put it in pluginManagement (it reverts to version
2.7). But it does use the updated config for the maven-compiler-plugin and the
maven-resources-plugin. And even more bizarrely, it does use the
maven-javadoc-plugin config in plugin for all submodules even though the *whole
point* of the pluginManagement section is for config that applies to all
submodules. The plugin section *should not* apply to all submodules.
Even after all these years, Maven can still surprise me with new failures
stemming from its legion of unfortunate design decisions.
when bootstrapping into an empty directory with -Dappbase parameter, the version must be read first from the configuration in order to create a valid appbase after re-reading the just downloaded getdown.txt (in verisoned mode)
when bootstrapping into empty directory with -Dappbase=... the version from the fetched getdown.txt must be extracted before calling processArg(SysProps.overrideAppbase(_appbase)) - otherwise _version is -1 instead of the version provided in the just downloaded getdown.txt.
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.
Michael Bayne