found in the active list. Otherwise the 2 BTC default is used.
We get TradeStatistics3 objects from old retired PaymentMethods
which are not found in the active list.
Replace 'BiFunction<T, U, Boolean>' with the primitive specialisation
'BiPredicate<T, U>' in HashCashService & FilterManager.
As part of this, replace similar predicate constructs found elsewhere.
NOTE: This touches the DAO packages (trivially @ VoteResultService).
Problem: a
NoSuchMethodError: 'java.util.stream.Collector
com.google.common.collect.ImmutableMultiset.toImmutableMultiset()'
exception was being thrown when testing the previously-merged upgrade to
Gradle 7.3, as described at keybase://chat/bisq#testing/2466.
Solution: This problem is similar to the issue reported at
jeremylong/DependencyCheck#3221. The source of the problem was multiple
conflicting guava jars on the runtime classpath. This commit upgrades to
guava 30.1.1-jre which ensures a single jar on the classpath.
Problem: a
NoSuchMethodError: 'java.util.stream.Collector
com.google.common.collect.ImmutableMultiset.toImmutableMultiset()'
exception was being thrown when testing the previously-merged upgrade to
Gradle 7.3, as described at keybase://chat/bisq#testing/2466.
Solution: This problem is similar to the issue reported at
jeremylong/DependencyCheck#3221. The source of the problem was multiple
conflicting guava jars on the runtime classpath. This commit upgrades to
guava 30.1.1-jre which ensures a single jar on the classpath.
Problem: When merging #5824, the absence of this entry caused a build
failure at dependency verification time against JDK11 and JDK15 on
Ubuntu-latest [1]. It may also cause failures on other JDK/OS
combinations, but the GitHub workflow was aborted before those failures
couldhave occurred. In any case, this omission did not create build
failures on any of the local development machines that tested the
aforementioned PR. Reasons for this discrepancy are unknown.
Solution: manually fetch the pom from [2], run `sha256sum` on it locally
and commit the result to the verification metadata file.
[1]: https://github.com/bisq-network/bisq/runs/4249640611?check_suite_focus=true#step:6:33
[2]: https://repo1.maven.org/maven2/com/fasterxml/jackson/jackson-base/2.11.1/jackson-base-2.11.1.pom
Problem: after the upgrade from 6.6.1 to 7.3, the usual invocation of,
e.g. `./bisq-pricenode 2 2` started failing as reported by @emzy at [1].
bisq@ubuntu-4gb-fsn1-1:~$ /bisq/bisq/bisq-pricenode 2
Error: Could not find or load main class 2
Caused by: java.lang.ClassNotFoundException: 2
Solution: for unknown reasons, the bisq-pricenode script worked as
expected under 6.6.1, i.e. contained the fq main class name in its
scripted invocation of `java -jar ...`, but under 7.3, this main class
name was missing. Through trial and error, it turns out that setting
`mainClassName` explicitly in the :pricenode subproject configuration
solves this problem and makes the start script work as expected.
Presumably, this problem arose in conjunction with the major version
upgrade of the spring boot Gradle plugin that was necessary when
upgrading to Gradle 7.3, but this has not been verified.
[1]: https://github.com/bisq-network/bisq/pull/5824#issuecomment-968276686
Problem: ClassNotFoundError was getting thrown when attempting to run,
e.g. the `./bisq-desktop` or `./bisq-pricenode` start scripts.
Solution: Gradle's posix start scripts were changed significantly
between 6.6.1 and 7.3, including a change to the way the current
directory is determined. This change updates the way we customize start
script generation to allow running them from the root of the repo. This
change only affects the unix / posix variants. The Windows .bat files do
not need to be adapted similarly.
- Made several adjustments to CLI's 'gettrade' output related code
so it can show single trade details for either Bisq v1 trades, or
BSQ swap trades.
- Did minor refactoring of API's core to retrieve # tx confirmations
for an addresses and transactions.
- Show # of tx confirmations in bsq swap trade detail.
That check is done if:
- If we are after activation time
- If filter is available
- If value in filter is > 0
The check compares the paid fee and the fee value from filter
and requires that paid fee is > 70% of filter value.
See comments in code for more background.
