The controlsfx is a huge JavaFX components library (0.83MB as JAR).
Turns out, we only use a single component, the PopOver. Fortunately,
the PopOver is self-contained and easy to pull out from controlsfx.
This commit embeds the PopOver in the project and removes controlsfx
dependency. The embedded version is exactly the same as previously
used in the project, so no change in semantics should occur.
The reactfx was a 0.33MB dependency / 238 Java source files.
We only used it for FxTimer helper and to measure FPS in development mode.
The small FxTimer class got copied over into the project,
so there is no change in semantics.
The FPS measurement got replaced w/ com.sun.javafx.perf.PerformanceTracker,
an internal but long stable part of JavaFx. This is probably not a problem,
because it only concerns a rarely used, developer feature.
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.
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.
This performs the same function that the maven-enforcer-plugin did in
the pom removed by the previous commit, and also includes a more
comprehensive / up-to-date set of dependencies.
Note that the gradle-witness jar checked in here is one built from the
pull request in signalapp/gradle-witness#26.
This commit makes the following improvements upon the stock
javafx.gradle file introduced in the previous commit:
- Swap Maven Central for JCenter
- Remove mavenLocal entirely
- Update naming for clarity
See #66
The plugin's jfx* tasks tie into the normal Gradle build lifecycle, such
that `gradle build` will now generate executables and installers
according to the OS on which the build is being run. These files are
output to the `build/distributions` directory.
Installers work as expected OS X and Linux at this point.
Windows installers do build, but a very particular configuration is
necessary on the Windows machine doing the building (this configuration
is to be documented in #109). However, even when the configuration is in
place and the MSI installer is successfully built, there is still a
fatal error at installer execution time relating to a missing
msvp100.dll file. See details at
https://bitbucket.org/shemnon/javafx-gradle/issue/43. An issue has been
created to track this from the Bitsquare side as well--see #108.
The changes made in this commit are based on on the samples at
http://bitbucket.org/shemnon/javafx-gradle and the article at
http://jaxenter.com/tutorial-a-guide-to-the-gradle-javafx-plugin-46270.html
The gradle/javafx.gradle file is copied directly from the sources in the
bitbucket repository above, as is apparently the convention (not sure
why this isn't part of the plugin itself, but that's a question to be
addressed later).
Resolves#66, #100
See #108, #109
Commit 4d4787d updated the Gradle wrapper config from 2.0 => 2.1, but
did not actually update the wrapper properties file (forgot to run
`gradle wrapper`). This commit finishes what was started there.
