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.
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.
It wasn't actually providing any value. Neither tools nor core have any special
dependencies. The code in tools operates on the same files, formats and data
structures that core/runtime code operates on. It is simpler to have them in
the same module.
I don't want to pollute the com.threerings top-level namespace with a bunch of
getdown-foo artifacts, and grouping everything under the top-level project
name, even when that name is repeated for all the artifacts is fairly standard
practice.
- core: the main Getdown logic code
- tools: code to create digest.txt & patch files
- launcher: the standalone launcher/updater app
- ant: the Ant task for creating digest.txt files
This paves the way for a proper Jigsaw-ification of the Getdown code.
I may further factor code out of getdown-launcher and into getdown-core to
enable the use-case where an app embeds Getdown completely and does not use the
launcher app/UI. That will also make it easier to create a JavaFX UI and retire
the old Swing UI.
This also moves the obsolete applet code into a separate applet module, which
is merely a temporary holding area. It will be deleted in the next commit.
This upgrades a bunch of Maven plugins, upgrades Proguard to 6.0, and adds some
fiddly profile stuff to point Proguard at the right set of JDK jmods since
rt.jar no longer exists for Java 9, and ignores a bunch more samskivert library
stuff since it references Java modules that we don't use (like java.sql).
Whenever 'use_code_cache' is set to 'true' the application's code
resources are copied to a cache directory prior to launching the
application. This is done in order to support multiple open application
instances of different versions.
Michael Bayne