Fix and improve natives extraction

[GoogleCodeExporter]

For distribution via protected store systems (e.g. Mac AppStore, Windows Store) 
simple applications like games ideally agree to restrict their access rights to 
a certain folder existing in the user home of the user executing the installer. 
The applications folder (Applications / Program Files) can not be written by 
the application, neither can the user root folder be written during execution. 
Only the files that came with the installer bundle from the store can be saved 
in the Application folder. The applications user folder is only used to store 
data like savegames and similar things.

As the natives needed for execution of jME applications are bundled in the jar 
file and normally get extracted by the natives system, this restriction would 
only allow to extract the natives to that specific application settings folder, 
the name of which would have to be transferred from the installer system to 
jme. The engine could use this path for Natives.setExtractionDir() then.

The problem is that the binaries should not be stored in a settings folder and 
that the only proper solution for applications distributed this way is to 
distribute the *extracted* binaries with the application. This would 
practically render the natives extraction useless but as some users will want 
to rely on the current system I suggest changing the natives handling the 
following way:

To allow easy switching to preinstalled binaries, the natives extraction should 
be smart about this and
a) check if the binaries are present even if the applications folder isn't 
writable
b) Ideally know the signature of the binary that is has to use with its own 
lwjgl version so no mismatches occurr (lwjgl helper class available?)
c) That'd also allow for not bundling the natives in a jar on the classpath  
but still being able to check those on disk. The installer would have installed 
them and doibling them in the jar isn't necessary.
d) still extract the binary to app dir, home dir or temp dir if its not 
available otherwise

Original issue reported on code.google.com by normen667 on 29 Jul 2012 at 1:34

[GoogleCodeExporter]

a) We can do this one. If getExtractionDir() fails to find a writable 
directory, it will enable "reuse natives" mode and use the working directory to 
search for them. If any required natives are not found, an exception will be 
raised. The user will have the option to turn on "reuse natives" mode forcibly 
in the edge-case that a writable directory is found but natives are bundled 
anyway.

b) This cannot be implemented, but IMO its a non-issue since a mismatch can 
only occur in "reuse natives" mode (see item a) which means you bundled the 
wrong natives with your app.

c) If running in "reuse natives" mode (see item a), then the natives jar is not 
required since the natives are not extracted in the first place. Otherwise the 
natives are required, and an exception will be thrown if they are missing.

d) In other words, "reuse natives" mode was not enabled.

This will satisfy 2 use cases from what I see:
1) User makes a regular release and an app store release. The regular release 
has a natives jar and the natives are not bundled in the working directory. The 
app store release has no natives jar and includes the natives in the working 
directory.
2) User makes a single release for both regular release and app store release. 
A natives jar is not used and the natives are in the working directory, for 
this case, "reuse natives" mode must be forcibly enabled.

Original comment by ShadowIs...@gmail.com on 4 Aug 2012 at 9:19

• Added labels: Component-System, Milestone-3.0-ReleaseCandiate

[GoogleCodeExporter]

Yep :)

Original comment by normen667 on 6 Aug 2012 at 11:07