This file was produced by adding a `-v` flag following the `-deploy`
flag in `package/windows.bat`. The creation of the file is reported by
javapackager as follows:
Config files are saved to
C:\Users\CBEAMS~1.WIN\AppData\Local\Temp\fxbundler5661616451276716144\windows.
Use them to customize package.
Subsequent commits will customize this file, primarily for the purpose
of avoid the dreaded 'missing dll' errors mentioned originally in
d16c274 and detailed at https://bitbucket.org/shemnon/javafx-gradle/issue/43.
This change allows users to place a bitsquare.properties file within
a `.bitsquare` directory under their home directory. This makes it
possible to specify property values (such as
node.useManualPortForwarding=true) that will survive cleaning the
application data dir (e.g. with `--clean=true` flag as introduced
in #291).
The precedence of this new "homeDirProperties" property source is lower
than the "appDirProperties" property source.
This means that if a user has a `bitsquare.properties` file both in his
home directory and in his application data directory, both files will be
processed, but for any properties that exist in both files, the property
specified in the application data directory file will take precedence.
This arrangement allows users to customize settings on an app-by-app
basis, which is especially useful in local testing scenarios where more
than one Bitsquare instance is running.
Prior to this change, the "clean flag" was named `user.data.clean.dir`,
but in fact it cleaned the *app* data dir, not the *user* data dir.
This is the difference betwen deleting
~/Library/Application Support (the "user data dir")
vs.
~/Library/Application Support/Bitsquare (the "app data dir")
The name of this flag has been updated to `--app.data.dir.clean` to
reflect the fact that it cleans the latter vs. the former.
The processing of this flag has also been updated. It's default value
(false) is now assigned during the creation of the default properties
source in BitsquareEnvironment, and instead of reading and handling the
flag directly in the BitsquareEnvironment constructor, we now handle
cleaning in BitsquareApp#initAppDir, where logic for handling the
creation of the directory already exists.
See #291
