Protobuf got updated to the latest released version 3.9.1.
The main motivation was to fix the following annoying warnings:
WARNING: An illegal reflective access operation has occurred
WARNING: Illegal reflective access by com.google.protobuf.UnsafeUtil (file:/home/qertoip/.gradle/caches/modules-2/files-2.1/com.google.protobuf/protobuf-java/3.5.1/8c3492f7662fa1cbf8ca76a0f5eb1146f7725acd/protobuf-java-3.5.1.jar) to field java.nio.Buffer.address
WARNING: Please consider reporting this to the maintainers of com.google.protobuf.UnsafeUtil
WARNING: Use --illegal-access=warn to enable warnings of further illegal reflective access operations
WARNING: All illegal access operations will be denied in a future release
Additionally, protobuf-gradle-plugin got updated to 0.8.10.
Created version variables in build.gradle where missing,
but not touching hard coded overrides in subprojects.
Alphanumerically ordered version variables.
Used IDE code formatter, changing top line of file.
If a seednode is using netwlayer version 0.6.2 (or 0.6.1) it is not
reachable from other nodes. Still unclear what causes that and if it
would affect also normal Bisq nodes, but to be careful we revert to
latest stable netlayer version which fixes the issue.
We used checkpoint files from BitcoinJ 0.14.4 and those caused a very
slow initial download. I tested with the WalletAppKit and different
release version sof BitcoinJ and could reproduce the behaviour there.
WIth v0.14.5 it was much better. But also that caused slow startup in
Bisq. After creating a current checkpoint file and using that the
download is now very fast.
Also added logging for versions of BitcoinJ and libDohJ so that we have
better control which version is used.
Prior to this fix, the build failed with the following error:
FAILURE: Build failed with an exception.
* Where:
Build file '/Users/cbeams/Work/bisq-network/bisq/build.gradle' line: 109
* What went wrong:
Execution failed for task ':desktop:installDist'.
> No such property: bat for class: java.lang.String
@cbeams
The copy task below fails because the copied files are conflicting
with the project folder name.
I temporarily delete those files as I think they are duplicated
anyway (bisq-* are probably the one to use). Would be good if those
files don't get created in the first place.
The related *.bat files are also deleted.
I push that change directly as currently both master and release
branch fail to build.
Related to https://github.com/bisq-network/bisq/pull/1959 which
removed .bat files on a non-Windows OS to prevent a cluttered root
directory, this change will delete *nix scripts on a Windows OS.
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
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.
Updating to the latest shadow plugin version will resolve the following
deprecation warning:
> Task :desktop:shadowJar UP-TO-DATE
Registering invalid inputs and outputs via TaskInputs and TaskOutputs
methods has been deprecated. This is scheduled to be removed in Gradle
5.0. A problem was found with the configuration of task
':desktop:shadowJar'.
See: https://github.com/johnrengelman/shadow/issues/336
This change avoids the as-yet unexplained resolution errors we've been
seeing out of JCenter today, which look like the following:
Could not resolve all files for configuration ':monitor:compileClass
> Could not resolve net.gpedro.integrations.slack:slack-webhook:1.1.
Required by:
project :monitor
> Could not resolve net.gpedro.integrations.slack:slack-webhook:1
> Could not get resource 'http://jcenter.bintray.com/net/gpedr
> Could not HEAD 'http://jcenter.bintray.com/net/gpedro/int
> sun.security.validator.ValidatorException: PKIX path b
For full context, see the Travis CI build failure at
https://travis-ci.org/bisq-network/bisq/builds/451786384#L678-L679.
It is assumed this is an issue on the JCenter side, e.g. something to do
with the interaction of JCenter servers and their SSL implementation
when accessed under OpenJDK 10 and its TrustStore implementation. This
specific failure does not occur under Oracle JDK 11, but other
dependencies do fail in a similar but non-deterministic fashion. In any
case, resolving project dependencies from Maven Central solves the
problem in the meantime.
See also https://github.com/gradle/gradle/issues/6630.
- Move mavenLocal on top to resolve local jars first
- Comment out annotationProcessor and testAnnotationProcessor entries as
they conflict with grpc build (don't know why). Complete project build
works also without the annotationProcessor entries.
- Comment out btcd-cli4j entries in dependencyVerification as they cause
build failure. TODO investigate why...
This does the work that was intended to be done in commit
175e11d81c, but was done by first removing
the dependencyVerification block entirely, and then replacing it with
the output of the `calculateChecksums` task.
The entire process went like this:
1. Remove existing dependencyVerification block from build.gradle
2. Run `./gradlew -q calculateChecksums | grep -v network.bisq:bisq- >> build.gradle`
3. Run `git diff` to see that only the checksums we expect to have
changed have in fact changed (libdohj and bitcoinj in this case).
4. Commit the changes (in this commit)
I'll update the instructions for the dependencyVerification block in a
subsequent commit to make this clearer in the future.
The calculated checksum from the calculateChecksums task did not
reflect updates of libdohj and bitcoinj.
libdohj is a dependency in common but seems the calculateChecksums task
in desktop did not resolve that correctly. It did not change the
checksum after the libdohj version has changed and led to build errors.
Adding the libdohj dependency in Desktop as well solves the issue.
@bceams: If there is a better solution to solve that feel free to
revert and apply....
Setting this value to `false` was a minor optimization to improve build
speed, as we don't need both tar and zip dists to be built (and zip
actually takes a few seconds).
PR #1500 set it to `true`, because it ended up causing build failures
down the road. This commit removes the statement altogether, as `true`
is the default value anyway.
Recent changes to dependencyVerification got committed with 8-space
indentation, causing a diff for the whole block. This reverts it to
4-space, which is what is generated by `gradle -q calculateChecksums`.
