The bisq.java-integration-tests plugin creates an integrationTest source
set that depends on JUnit. The source set inherits the main source set's
compile classpath, runtime classpath, and the implementation's source
set configuration and runtimeOnly configuration.
With the introduction of the javacv library when re-adding the QR code
scanner feature for mobile notification pairing in #7050, the Bisq
binary increased to nearly 1 GB from its previous size of around 300 MB.
When including the javacv-platform dependency, it pulls in binaries
for all platforms. But it is possible to limit this by utilizing
the gradle-javacpp platform plugin which by default will pull in
binaries only for the current platform.
Reference: https://github.com/bytedeco/gradle-javacpp#the-platform-plugin
With this change, the included libs went from ~980 MB down to ~366 MB.
With the introduction of the javacv library when re-adding the QR code
scanner feature for mobile notification pairing in #7050, the Bisq
binary increased to nearly 1 GB from its previous size of around 300 MB.
When including the javacv-platform dependency, it pulls in binaries
for all platforms. But it is possible to limit this by utilizing
the gradle-javacpp platform plugin which by default will pull in
binaries only for the current platform.
Reference: https://github.com/bytedeco/gradle-javacpp#the-platform-plugin
With this change, the included libs went from ~980 MB down to ~366 MB.
This restores the functionality that was removed in b5beea58. However,
this implementation utilizes the JavaCV library rather than the
webcam-capture library as discussed in #4940. As a result, this should
now provide macOS support.
Done via `./gradlew wrapper --gradle-version 7.3.3 --distribution-type all`
From the release description:
This is a patch release for Gradle 7.3.
It fixes the following issues:
* #19360 Upgrade checks to Log4j 2.17.0
We recommend users upgrade to 7.3.3 instead of 7.3.
See also https://github.com/gradle/gradle/releases/tag/v7.3.3
This change upgrades log4j to patch fixes for recently documented
CVE-2021-45046 CVE-2021-45105 vulnerabilities related to the Log4Shell
exploit.
Like the earlier fix, Bisq does not appear to be vulnerable to these
exploits because it does not use log4j directly, only transitively
depends on it. Nevertheless, the upgrade is still the safe bet.
This commit upgrades our transitive dependency on Log4J 2 from 2.14.1 to
the newly-released 2.15.0 to avoid the CVE described at
https://www.lunasec.io/docs/blog/log4j-zero-day/.
We do not use log4j directly anywhere in our codebase, so our exposure
to this exploit was already mitigated if not eliminated, but Spring Boot
depends on Log4J 2 internally. This commit upgrades Spring Boot's
underlying dependency on Log4J to 2.15.0 in the manner recommended at
https://github.com/spring-projects/spring-boot/issues/28958.
This is in preparation for addressing log4j 2 zero day exploit described
at https://www.lunasec.io/docs/blog/log4j-zero-day/. See full details
in the next commit.
Bringing in the dependency-management plugin results in many changes to
our Gradle verification metadata file, but all are BOM / POM / Module
manifests. No additional jar or code dependencies have been whitelisted
with this change.
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.
