Several repos are to be extracted from the main bisq repo, and their
distribution versions need to match the bisq desktop's version.
This change moves the desktop version property definition to a file
that can be read from Gradle builds having the bisq git submodule dependency,
i.e., version = file("bisq/desktop/src/main/resources/version.txt").text.trim()
Based on `master`.
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.
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.
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
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: 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.
As mentioned in a prior commit, the upgrade to Gradle 7.x results in
many more dependency declarations in the file, many of which are
effectively duplicates. This change does not attempt to eliminate those
duplications in any clever way, but rather just tidies up and organizes
all dependency declarations by sorting them alphabetically.
