We had historically higher trade limits and assets which are not in the
currency list anymore, so we apply the filter only for data after
Nov 1st 2021.
This change sets java source and class generation version targets to 11.
The Bisq distribution is built with JDK 11, but source target has remained at 1.10.
Upgrading allows devs to use some Java syntax features available @since 11, and it
might help anyone building the src avoid confusion over which JDK they should use
(minimum is JDK 11).
See https://docs.gradle.org/current/userguide/java_plugin.html#sec:java-extension
PaymentMethod use an instance of TradeLimits and expect that it
has been injected, which is the case for desktop but not for
headless apps, so we enforce injection in the app base classes
used for headless apps.
The validation of trade statistics use a method in PaymentMethod
where that dependency is required.
Tha hack how the PaymentMethod use TradeLimits is not nice, but
would require more effort for refactoring.
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.
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
