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.
The "Trusted-Library" manifest attribute is required for Applets and
Java Web Start. Otherwise classes from the Getdown package might be
silently ignored (ClassNotFoundException).
We have an ant build.xml and a maven pom.xml. At some point I guess the
build switched to maven, which didn't have the special manifest to use
for the jar to work around all the Java permission changes. If you want
getdown to work with the latest Java, you will need to use this update.
Proguard 5.x finally supports Java 8. We don't compile Getdown to Java 8
bytecode, but Progaurd has to grok the stdlib of the JVM being used to run
Proguard, which previously meant that we couldn't compile Getdown with a Java 8
JVM, which was annoying. Now we can. Yay!
Michael Bayne