This makes sense given that we already support app_id-prefixed apparg
parameters, and one might want to configure the JVM specially for different
apps from the same installation.
Note: unlike apparg, app_id-prefixed jvmargs are appended to un-prefixed
jvmargs rather than replacing them. I think this makes sense because you
probably want to specify standard JVM args and then maybe tweak a thing or two
for your other app. This is also backward compatible which is usually a good
thing. It does mean that it's harder to "undo" a jvmarg set for your "default"
app, in such cases you'd probably have to not have a default app and instead
identify all of your apps with app_ids.
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.
Michael Bayne