IDE users should ignore metafiles for their preferred IDE once in their own
global .gitignore instead of burdening every project in the Universe with
ignore directives.
Create ~/.gitconfig, add to it:
[core]
excludesfile = ~/.gitignore
Create ~/.gitignore, add to it:
/.classpath
/.project
/.settings/
This relies on the existence of a 'release' file in the top-level of the
unpacked JVM. If no 'release' file exists (or it can't be read) then we fall
back to the old behavior which is to assume that an unpacked JVM meets the
app's version requirements.
This also assumes that the java_version_regex configured for the app is capable
of parsing the version string in the release file. The release file appears to
contain a string that matches the system property 'java.version', so if you are
doing version shenanigans and using 'java.runtime.version', you need to do one
of two things:
1. Make sure your regexp can handle missing bits and that the lack of said bits
doesn't hose your version checks. For example, if you need 1.8.0_42-b15 and
your version regexp turns that into 108004215, but the release file just
contains 1.8.0_42 which your version regexp turns into 108004200, then you're
going to have a problem. But if your minimum version is some previous patch
release (say 1.8.0_25-b32) and the custom JVM you ship is 1.8.0_42, then you'll
be OK because 108004200 > 108002532.
2. Create your own 'release' file in your custom packaged JVM (or modify the
existing one) which contains a line with the following syntax:
JAVA_VERSION="VVV"
where VVV is the full version string that your regexp expects. It will be
extracted and parsed with your regexp, and everything will be peachy.
For example:
java_version_prop = java.runtime.version
java_version_regex = (\d+)\.(\d+)\.(\d+)(_\d+)?(-b\d+)?
Note: double backslashes are not needed in getdown.txt.
This preserves existing functionality, but accomplishes it with a general
purpose method that can parse any Java version string, given a regular
expression that matches all the number parts (which have to be in most to least
significant order).
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!
This unfortunately relies on _app.init() happening *inside* detect proxy in the
particular code path that results in failed proxy detection. I wish app.init
wasn't such a twisty maze of spaghetti, but that ship has long since sailed.
This reverts commit 12f7b666af.
So it turns out despite getdown being public and having an
automatic travis build we still have an internal build. Which
uses ant. And requires blood sacrifices to cope with maven.
I'm really not in the mood to deal with it/don't have access to
set up the travis build to publish snapshots, so I'm just going to
revert and let someone else with more motivation clean up this mess
(or not)
Michael Bayne