In practice we always use TomP2P's in-memory storage. Eliminate the
useDiskStorage option for now, in order to simplify the ongoing
refactoring efforts.
Refer to the "name" of a node rather than its "id". This is reflected in
the command line options as well. Instead of `--id`, now pass `--name`.
Instead of `--bootstrap.node.id`, now pass `--bootstrap.node.id`.
This change does away with the notion of "clientPort" and replaces it,
simply, with "port". There are only two ports we care about in
Bitsquare:
1. The port that the local node (i.e. a Bitsquare UI running on
your laptop) listens on. This value is now specified with `--port`
2. The port of the bootstrap node that the local node will connect to on
its first run. This value is specified with `--bootstrap.node.port`
So, for example, the following is a valid commandline invocation:
java -jar bitsquare.jar --port 1234 --bootstrap.node.port=9876
Both of these values default to Node.DEFAULT_PORT (currently 7366)
This commit also introduces the --id flag for configuring the ID of the
local node.
This change clarifies the relationship between the Bitsquare node that
is being run (the local node) and the Bitsquare node that the local node
is being bootstrapped against (the bootstrap node).
Prior to this change, customizing bootstrap node looked like this:
java -jar bitsquare.jar --ip=203.0.113.3
Now it looks like this:
java -jar bitsquare.jar --bootstrap.node.ip=203.0.113.3
This change also removes entirely the short option strings (-d, -s, -p,
-i) for simplicity and clarity while these values are undergoing change.
By qualifying bootstrap node options explicitly in this fashion, we make
way for customizing the the same values against the local node. These
changes will come with subsequent commits.
This change moves the NETWORK_INTERFACE_KEY into
BootstrappedPeerFactory, where it is actually used, but because
BootstrappedPeerFactory is package-private and has no other reason to be
public, NETWORK_INTERFACE_KEY is re-exposed publicly through
TomP2PMessageModule, where it can be used by types in the
io.bitsquare.app* packages.
Like all other command-line options and/or configuration file
properties, appName is now parsed for early in #main and its value
(default or custom) is then used to populate the Properties object made
available to all Guice modules. See the previous commit for additional
details.
This reverts a number of changes made in commit 3033a19. Primary changes
include:
- Restoring the immutability of the Node class
- The argparse4j Namespace object is no longer passed down through
Guice modules
- Instead, arguments are eagerly read from the Namespace object by the
#main method and these values are used to populate the Properties
object that is already supplied to each Guice module
Other changes include:
- The addition of a BootstrapNodes#DEFAULT_BOOTSTRAP_NODE field as
a convenient alias to BootstrapNodes#DIGITAL_OCEAN_1 (or whatever the
future default bootstrap node may be)
- A Node#getPortAsString method has been added for convenience when
dealing with String-based properties
- A variant of the Node#at static factory method has been added which
accepts the port value as a String vs. an int--again this is for
convenience when dealing with String-based properties
- Tests have been added to NodeTests to reflect the above
Prior to this commit, Gradle was configured to take a -Pargs property
and split the value on whitespace, passing the result to the Gradle
application plugin's 'args' property, for example:
gradle run -Pargs="--id=foo --ip=1.1.1.1 --port=10001"
While this approach works fine when passing a single argument (i.e. when
no space delimiters are required), when multiple arguments are passed,
such as in the example above, it would result in the following error
from Gradle's own command line parser:
Unknown command-line option '--ip'
This commit simply splits the value of -Pargs on commas rather than
spaces, meaning that now multiple -Pargs values should be supplied as
follows:
gradle run -Pargs="--id=foo,--ip=1.1.1.1,--port=10001"
Resolves#264
