This temporary subclass introduces the same change proposed in
spring-projects/spring-framework#693, and should be removed when that
pull request is merged and made available.
This commit introduces io.bitsquare.network.ClientNode--an interface
whose name and structure will surely change--as a simplistic abstraction
over TomP2PNode that allows for exposing information to the "Network"
tab of the Preferences section of the GUI without actually requiring the
injection of TomP2PNode and other tomp2p internals into the GUI layer.
Changes to 'network' and 'msg' packages:
----------------------------------------
- Move ConnectionType enum from test into main tree, and expose
ClientNode#getConnectionType.
- Both ClientNode and TomP2P are now available for injection. Both
types are bound to the same TomP2P singleton instance. Note
especially how NetworkPreferencesViewCB now receives a ClientNode
instead of a TomP2PNode.
- Restore package-private visibility to BootstrappedPeerFactory
- Remove no longer necessary TomP2PNode#getPeerDHT
- Expose getter for BootstrappedPeerFactory#bootstrapState
Changes to 'gui' package:
-------------------------
- NetworkPreferencesViewCB has been simplified. All no-op methods have
been removed, and the class now simply implements JavaFX's
Initializable interface as opposed to Bitsquare's own ViewCB
hierarchy, because the latter is not actually necessary (no caching
is required for the data handled by this controller, etc.
- In order to make the above possible, PreferencesViewCB now tolerates
adding non-ViewCB child controllers.
- NetworkPreferencesPM has been removed (perhaps temporarily), in an
experiment to see "just how simple" CB controller classes can be.
- Text fields in NetworkPreferencesView have been renamed.
Notes:
------
The data that now shows up in the "Network" tab is no longer formatted
as it once was; values are essentially nothing more than their #toString
representations. Again, this can be tweaked further, but leaving things
in this raw state provides an opportunity to discuss the current
presentation model approach, ViewCB hierarchy, etc.
SignatureService methods are now generic with respect to Bitsquare's
domain, i.e. there is no longer any awareness of "contracts",
"registration data", or the like. In fact, because SignatureService
holds no state whatsoever, it would be reasonable to refactor the class
into a set of static utility methods. However, this change leaves
SignatureService as a DI-managed POJO for the time being.
Major changes:
- Rename #signContract => #signMessage
- Rename #getEmbeddedAccountRegistrationData => #digestMessageWithSignature
The build now exposes two explicit ShadowJar tasks: one for the main
JavaFX client (`appJar`) and one for the headless bootstrap node
(`bootstrapNodeJar`).
Run as follows:
./gradlew appJar
-- or --
./gradlew bootstrapNodeJar
The resulting executable jar for each will be found in the `build/libs`
directory.
Thanks to @johnrengleman for his help at johnrengelman/shadow#108
Resolves#265Resolves#252
* cbeams:
Reorder methods in BitsquareEnvironment for clarity
Introduce 'app.version' property and remove hardcoded version
Use Preconditions#checkNotNull vs. #checkArgument
Rename name, port properties to node.name, node.port
Remove unused ApplicationPreferences variable
Rename config file from bitsquare.{conf=>properties}
- 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.
These changes eliminate the use of "appName" throughout the codebase in
favor of explicitly named, and therefore individually configurable
alternatives specific to each component. For example, instead of passing
the application name through the WalletFacade boundary and then using a
utility like AppDirectory to put construct the wallet directory on the
fly, the path to wallet directory is now passed explicitly as a
@Named(WALLET_DIR) parameter to the WalletFacade constructor.
The result is not only better configurability (e.g. the WALLET_DIR
property can be overridden without affecting any other parts of the
system), but also better understandability. See
BitsquareEnvironment#defaultProperties to see how it all comes together.
Note how the value of appName is mapped to each of these new properties,
all in one place where it's easy to get an overview etc.
Also, as of this commit, there is only one place in the codebase where
the word "Bitsquare" is hard-coded (in `i.b.app.BitsquareEnvironment`):
$ git grep -h '"Bitsquare"' src
public static final String DEFAULT_APP_NAME = "Bitsquare";
To keep things clean, further hard-coding should be avoided from this
point forward.
See extended comments for each commit for details.
* wip-cbeams:
Eliminate remaining uses of @Named("appName")
Introduce explicit title param in ViewCB
Introduce io.bitsquare.btc.UserAgent
Introduce explicit dir and prefix params in Persistence
Introduce explicit wallet and useragent params in WalletFacade
Rename environment "app properties"=>"default properties"
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.
Like previous commits, this change removes reliance on the global
"appName" in favor of an explicit and configurable "view.title"
parameter. It is still set by default to the value of appName, but this
assignment is now done in BitsquareEnvironment, as are the other similar
parameters that have been broken out in previous commits.
