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
Providing an explicit default using the #defaultsTo method ends up
short-circuiting the Spring Environment's hierarchical property resolution
process. for example, if --port.useManualPortForwarding has a default
value of `false`, then the command line property source always returns a
value when its #getProperty method is invoked by the Environment. This
means that a lower-precedence property source never has the opportunity
to return its value. For example, if port.useManualPortForwarding had
been set to true in the filesystem property source
(at ${user.data.dir}/bitsquare.properties), this property value would
never be resolved because the default command line property source always
overrides it (thus the notion of "short circuiting" above).
This change eliminates the use of JOpt's #defaultsTo method in favor of
a simple approach to advertising default values (if any) in the option's
description string. The result is --help output that reads exactly the
same as it did before, but no actual default value is set at the command
line property source level.
Note that the default property source is still created, and default
values are still assigned in BitsquareEnvironment#defaultPropertySource.
This property source has the lowest precedence, and this means that any
and all other property sources have the opportunity to provide a value
and override the default.
BitcoinNetwork now supports a #getParameters method that returns the
BitcoinJ NetworkParameters instance associated with the given
BitcoinNetwork enum label (e.g. TESTNET.getParameters() returns
TestNet3Params, etc).
BitcoinModule#BITCOIN_NETWORK_KEY and #DEFAULT_BITCOIN_NETWORK have been
moved to BitcoinNetwork#KEY and BitcoinNetwork#DEFAULT respectively.
Customzing the bitcoin network to use on the command line has been
improved. Values may be upper or lower case (e.g. "testnet", "TESTNET"),
and the value passed is converted to the correct BitcoinNetwork enum
value with the new EnumValueConverter class.
Finally, a BitcoinNetwork instance is now made available for injection
by BitcoinModule as opposed to binding a NetworkParameters instance. All
injection targets (constructors) throughout the codebase have been
updated to reflect this change, and the result is cleaner, enum-based
processing everywhere possible. And where it's necessary to drop down to
BitcoinJ's NetworkParameters, that's easy to do by calling
BitcoinNetwork#getParameters.
- Introduce a test-time dependency on spring-test module for access to
MockPropertySource and friends.
- Add BitsquareEnvironmentTests and test that property source precedence
works as expected, i.e. that properties supplied on the command line
have highest precedence, overriding those picked up via environment
variables, system properties, the bitsquare.properties file or any of
the other available property sources.
Changes include:
- Remove lighthouse.files.AppDirectory. Several methods from this class
have, as of this commit, been rewritten and moved into the
BitsquareEnvironment and BitsquareApp classes as appropriate.
- Rename "appName" property => "app.name" for consistency with other
configurable properties.
- Allow configuration of both user and application data directories on
the command line. See --help menu for details.
Use of the Spring Environment
-----------------------------
This change replaces the use of the argparse4j library and basic
Properties objects with the Spring Framework's Environment abstraction.
The Environment allows for managing any number of 'property sources' in
a hierarchical fashion, such that a call to
`environment.getProperty("someKey")` iterates through an ordered set of
property sources, returning the first value associated with the given
key.
BitsquareEnvironment, introduced in this commit, eliminates the
functionality previously present in ConfigLoader, modeling the
bitsquare.conf and bitsquare.properties files as Spring Resource
objects, and in turn creating ResourcePropertySources out of them. These
custom property sources are combined with standard property sources
based on system environment variables and Java system properties as well
as a property source based on the command-line arguments passed to a
Bitsquare application to form a unified, one-stop configuration
hierarchy.
For example, let's say a Bitsquare user wishes to customize the port
that his Bitsquare application listens on. The simplest approach
(assuming the user is comfortable with the command line), would be the
following:
java -jar bitsquare.jar --port=1234
where '1234' is the custom port of choice. This is convenient enough for
one-off experimentation, but if the user wishes to make this a permanent
arrangement, he may want to add a `port=1234` entry to his
{bitsquare_app_dir}/bitsquare.conf file.
Alternatively, the user may wish to specify the port value as an
environment variable, e.g.:
PORT=1234 java -jar bitsquare.jar
or with a JVM system property, e.g.:
java -jar -DPORT=1234 bitsquare.jar
With BitsquareEnvironment, and its customized set of PropertySources in
place, the value of the port property may be specified in any of the
ways described above, and it is all handled in a unified way.
Restructuring of *Main classes
------------------------------
This commit also introduces significant changes to the structure of
executable Bitsquare applications. For example, prior to this change,
the io.bitsquare.app.gui.Main class was responsible for being both a
JavaFX Application and a standard Java main class.
Now, however, these concerns have been renamed and separated.
BitsquareApp is the JavaFX Application, and BitsquareAppMain is the Java
main class. Likewise, BootstrapNode has been broken out into
BootstrapNode and BootstrapNodeMain.
A common base class for the *Main classes has been extracted, named
BitsquareExecutable, which creates a template for option parsing,
environment creation, and ultimately application execution that applies
both to the BootstrapNode and BitsquareApp cases.
Improved help text
------------------
With the removal of argparse4j and the introduction of JOpt for argument
parsing, the application's help text has been improved. Use --help to
display this text, where you'll see information about default values,
etc. To do this easily from the Gradle build, run any of the following
commands:
# Display help text
./gradlew run -Pargs="--help"
# Qualify the application name as "Bitsquare-Alice"
./gradlew run -Pargs="--appName=Alice"
# Customize the port
./gradlew run -Pargs="--port=7377"
Renaming of FatalException
--------------------------
Finally, the exception formerly known as io.bitsquare.gui.FatalException
has been moved up a package and generalized to
io.bitsquare.BitsquareException, as it is now used more widely.
