Previously, start scripts were generated for both *nix and Windows
platforms, resulting in an unnecessarily cluttered root directory.
With this change, both types of script are still generated, but Windows
.bat scripts are deleted immediately afterward if the user is running a
non-Windows OS (unfortunately, there was no clean way to suppress the
generation of these scripts in the Gradle StartScripts API).
See #1956
- Remove activationDate
- Refactor ProcessOfferAvailabilityResponse and handle offers from
old versions in case the available arbitrators has changed.
- Remove MakerVerifyMediatorSelection and TakerSelectArbitrator
The mediator handling should be removed as it is not used and not
intended anymore to be used with the current trade protocol, but we
leave that as it is a bit tricky to ensure backward compatibility.
Also the setting of the arbitrator in trade should be further refactored
but as it is also easy to break backward compatibility here we leave
that for now. As we work on the new trade protocol that domain will
become deprecated anyway in the next months...
This change configures the Gradle build to generate "start scripts" for
each Bisq executable (e.g. Bisq Desktop, Bisq Seednode, etc) in the root
project directory, such that after invoking `./gradle build`, the
following executable scripts become available:
~/Work/bisq-network/bisq
$ ls -1 | egrep '(bisq*|lib)'
bisq-desktop
bisq-desktop.bat
bisq-monitor
bisq-monitor.bat
bisq-relay
bisq-relay.bat
bisq-seednode
bisq-seednode.bat
bisq-statsnode
bisq-statsnode.bat
lib
This makes it possible for users (developers) to easily discover and use
these scripts in an idiomatic and platform-agnostic way as opposed to
the previous situation where we would advise users to run e.g.
java -jar desktop/build/libs/desktop-0.8.0-SNAPSHOT-all.jar
This approach works, but is cumbersome and focuses unnecessarily on the
Java-based nature of the project. Now, with the changes in this commit,
the user would simply run:
./bisq-desktop
The 'lib' directory shown above contains all the jar files necessary to
construct classpaths for these various scripts. The 'cleanInstallDist'
task deletes the 'bisq-*' files and the 'lib' directory, and the default
'clean' task has been configured to depend on the 'cleanInstallDist'
task to ensure this cleanup happens automatically when most users would
expect it.
In the future, these same scripts can be used when installing Bisq
executables properly on users' systems via package managers like Brew
and Apt. The goal is to have the user experience around running
`bisq-desktop` (and more importantly, the forthcoming `bisqd`) be
similar in every way to installing and using `bitcoind`, `lnd` and other
idiomatic *nix-style utilities, be they Bitcoin-related or not.
See the changes in docs/build.md and docs/dev-setup.md for a further
sense of the how this change impacts the developer experience.
This change suppresses help output when option parsing fails, e.g. due
to an unrecognized option being specified. This is in keeping with *nix
utility idioms; for example, notice what happens when running `git
--bogus` or `ls --bogus`: they output an error message, and in some
cases a usage message, but they do not print complete help text.
This approach is especially important in the case of an application like
Bisq, where there are many options and the help text is longer than a
typical screen, making it easy to miss the error message altogether, as
it is printed at the top of the screen.
This change also prints the error message to stderr vs stdout, which is
again in keeping with *nix utility idoms.
Usually Bisq is run from its 'shadow jar', i.e. the executable fat jar
that collapses all dependencies and resources into a single file. In that
scenario, only a single 'logback.xml' is included in the fat jar and all
is well.
However, when Bisq is run with a normal external classpath, e.g. from
within IDEA, when using `gradle :desktop:run` or when running one of the
Gradle-generated shell scripts under desktop/build/scripts, multiple
'logback.xml' files are present on the classpath, which causes Logback
to complain with messages like the following:
Found resource [logback.xml] at [file:.../desktop/build/resources/main/logback.xml]
Resource [logback.xml] occurs multiple times on the classpath.
Resource [logback.xml] occurs at [file:.../desktop/build/resources/main/logback.xml]
Resource [logback.xml] occurs at [jar:file:.../core/build/libs/core.jar!/logback.xml]
Note the last line above. The presence of 'logback.xml' in the bisq-core
jar is the 'duplicate'. This is Logback's way of warning the user that
it doesn't know which file should be considered canonical. The only way
to avoid this error message (and the many other lines that get output
along with it) is to remove the offending duplicate file.
This commit removes logback.xml from core to solve the problem described
above. The file is unnecessary in the context of running bisq-desktop,
bisq-seednode, etc, and the only context in which it would actually be
used is when running BisqHeadlessAppMain in core. With that said, the
configuration in the core logback.xml file is identical to the default
Logback configuration, so removing the file has no effect on the logging
output from BisqHeadlessAppMain, and furthermore, it appears that
BisqHeadlessAppMain is not actually in use anywhere right now (it was
added some months ago in anticipation of integrating the new HTTP API,
but this has yet to occur).
In a future change, we should probably return the core module to being a
pure library, without any main methods, and introduce a different
module, e.g. 'daemon' that contains the equivalent of
BisqHeadlessAppMain and whatever logback.xml configuration is
appropriate for it. Doing things this way will avoid the 'duplicate'
errors shown above, because desktop, seednode, etc will not depend on
core module, but will not depend on the daemon module.
This code is no longer necessary after the recent move to JDK10, and
removing it entirely avoids spending unnecessary cycles and eliminates
the confusing "Cryptography restrictions removal not needed" message in
console output.
