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.
