bisq/build.gradle

716 lines
28 KiB
Groovy
Raw Normal View History

buildscript {
repositories {
mavenCentral()
maven { url "https://jitpack.io" }
}
dependencies {
classpath 'com.google.protobuf:protobuf-gradle-plugin:0.8.10'
classpath 'com.google.gradle:osdetector-gradle-plugin:1.6.0'
classpath 'com.github.johnrengelman:shadow:5.2.0'
classpath files('gradle/witness/gradle-witness.jar')
classpath 'org.springframework.boot:spring-boot-gradle-plugin:1.5.10.RELEASE'
}
}
Generate scripts for Bisq executables in root dir 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.
2018-11-23 14:33:44 +01:00
configure(rootProject) {
// remove the 'bisq-*' scripts and 'lib' dir generated by the 'installDist' task
task clean {
doLast {
delete fileTree(dir: rootProject.projectDir, include: 'bisq-*'), 'lib'
}
}
}
configure(subprojects) {
apply plugin: 'java'
apply plugin: 'com.google.osdetector'
sourceCompatibility = 1.10
ext { // in alphabetical order
bcVersion = '1.63'
bitcoinjVersion = '2a80db4'
codecVersion = '1.13'
easybindVersion = '1.0.3'
easyVersion = '4.0.1'
findbugsVersion = '3.0.2'
firebaseVersion = '6.2.0'
fontawesomefxVersion = '8.0.0'
fontawesomefxCommonsVersion = '9.1.2'
fontawesomefxMaterialdesignfontVersion = '2.0.26-9.1.2'
Introduce gRPC API proof of concept This commit introduces a new `grpc` module including the following key types: - BisqGrpcServer: The API implementation itself, along with generated gRPC Response/Reploy types defined in grpc/src/main/proto/grpc.proto. - BisqGrpcServerMain: A 'headless' / daemon-like entry point for running a Bisq node without the JavaFX desktop UI. - BisqGrpcClient: A simple, repl-style client for the API that allows the user to exercise the various endpoints as seen in the example below. In the `desktop` module, the BisqAppMain class has been modified to start a BisqGrpcServer instance if the `--desktopWithGrpcApi` option has been set to `true`. In the `core` module, a new `CoreApi` class has been introduced providing a kind of comprehensive facade for all Bisq functionality to be exposed via the RPC API. How to explore the proof of concept: 1. Run the main() method in BisqAppMain providing `--desktopWithGrpcApi=true` as a program argument or alternatively, run the main() method in BisqGrpcServerMain, where no special option is required. In either case, you'll notice the following entry in the log output: INFO bisq.grpc.BisqGrpcServer: Server started, listening on 8888 2. Now run the main() method in BisqGrpcClient. Once it has started up you are connected to the gRPC server started in step 1 above. To exercise the API, type `getVersion` via stdin and hit return. You should see the following response: INFO bisq.grpc.BisqGrpcClient - 1.2.4 Likewise, you can type `getBalance` and you'll see the following response: INFO bisq.grpc.BisqGrpcClient - 0.00 BTC and so forth for each of the implemented endpoints. For a list of implemented endpoints, see BisqGrpcServer.start(). Note once again that the code here is merely a proof of concept and should not be considered complete or production-ready in any way. In a subsequent commit, the `--desktopWithGrpcApi` option will be disabled in order to avoid any potential production use. The content of this commit is the result of squashing a number of commits originally authored by chimp1984 in the `chimp1984` fork's `grpc` branch. Co-authored-by: Chris Beams <chris@beams.io>
2019-09-18 18:39:37 +02:00
grpcVersion = '1.25.0'
gsonVersion = '2.8.5'
guavaVersion = '28.2-jre'
guiceVersion = '4.2.2'
hamcrestVersion = '1.3'
httpclientVersion = '4.5.12'
httpcoreVersion = '4.4.13'
ioVersion = '2.6'
jacksonVersion = '2.12.1'
javafxVersion = '15'
javaxAnnotationVersion = '1.2'
jcsvVersion = '1.4.0'
jetbrainsAnnotationsVersion = '13.0'
jfoenixVersion = '9.0.10'
joptVersion = '5.0.4'
jsonsimpleVersion = '1.1.1'
jsonrpc4jVersion = '1.6.0.bisq.1'
junitVersion = '4.12'
jupiterVersion = '5.7.0'
kotlinVersion = '1.3.41'
knowmXchangeVersion = '4.4.2'
langVersion = '3.11'
logbackVersion = '1.1.11'
loggingVersion = '1.2'
lombokVersion = '1.18.12'
mockitoVersion = '3.5.15'
netlayerVersion = '8db4a13' // Commit ID from https://github.com/bisq-network/netlayer/commits/externaltor
protobufVersion = '3.10.0'
protocVersion = protobufVersion
pushyVersion = '0.13.2'
qrgenVersion = '1.3'
slf4jVersion = '1.7.30'
sparkVersion = '2.5.2'
springBootVersion = '1.5.10.RELEASE'
os = osdetector.os == 'osx' ? 'mac' : osdetector.os == 'windows' ? 'win' : osdetector.os
}
repositories {
mavenCentral()
maven { url 'https://jitpack.io' }
}
dependencies {
testCompile "junit:junit:$junitVersion"
}
tasks.withType(JavaCompile) {
options.encoding = 'UTF-8'
}
}
configure([project(':cli'),
project(':daemon'),
project(':desktop'),
project(':monitor'),
project(':relay'),
project(':seednode'),
project(':statsnode'),
project(':pricenode'),
project(':inventory'),
project(':apitest')]) {
Generate scripts for Bisq executables in root dir 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.
2018-11-23 14:33:44 +01:00
apply plugin: 'application'
build.dependsOn installDist
installDist.destinationDir = file('build/app')
distZip.enabled = false
Generate scripts for Bisq executables in root dir 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.
2018-11-23 14:33:44 +01:00
// the 'installDist' and 'startScripts' blocks below configure bisq executables to put
// generated shell scripts in the root project directory, such that users can easily
// discover and invoke e.g. ./bisq-desktop, ./bisq-seednode, etc.
// See https://stackoverflow.com/q/46327736 for details.
installDist {
doLast {
// copy generated shell scripts, e.g. `bisq-desktop` directly to the project
// root directory for discoverability and ease of use
Generate scripts for Bisq executables in root dir 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.
2018-11-23 14:33:44 +01:00
copy {
from "$destinationDir/bin"
into rootProject.projectDir
}
// copy libs required for generated shell script classpaths to 'lib' dir under
// the project root directory
copy {
from "$destinationDir/lib"
into "${rootProject.projectDir}/lib"
}
2018-11-27 02:52:35 +01:00
// edit generated shell scripts such that they expect to be executed in the
// project root dir as opposed to a 'bin' subdirectory
def windowsScriptFile = file("${rootProject.projectDir}/bisq-${applicationName}.bat")
2018-11-27 02:52:35 +01:00
windowsScriptFile.text = windowsScriptFile.text.replace(
'set APP_HOME=%DIRNAME%..', 'set APP_HOME=%DIRNAME%')
def unixScriptFile = file("${rootProject.projectDir}/bisq-$applicationName")
unixScriptFile.text = unixScriptFile.text.replace(
'cd "`dirname \\"$PRG\\"`/.." >/dev/null', 'cd "`dirname \\"$PRG\\"`" >/dev/null')
2020-03-11 14:54:04 +01:00
if (applicationName == 'desktop') {
def script = file("${rootProject.projectDir}/bisq-$applicationName")
script.text = script.text.replace(
'DEFAULT_JVM_OPTS=""', 'DEFAULT_JVM_OPTS="-XX:MaxRAM=4g"')
}
if (applicationName == 'apitest') {
// Pass the logback config file as a system property to avoid chatty
// logback startup due to multiple logback.xml files in the classpath
// (:daemon & :cli).
def script = file("${rootProject.projectDir}/bisq-$applicationName")
script.text = script.text.replace(
'DEFAULT_JVM_OPTS=""', 'DEFAULT_JVM_OPTS="' +
'-Dlogback.configurationFile=apitest/build/resources/main/logback.xml"')
}
if (osdetector.os != 'windows')
delete fileTree(dir: rootProject.projectDir, include: 'bisq-*.bat')
else
delete fileTree(dir: rootProject.projectDir, include: 'bisq-*', exclude: '*.bat')
Generate scripts for Bisq executables in root dir 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.
2018-11-23 14:33:44 +01:00
}
}
startScripts {
// rename scripts from, e.g. `desktop` to `bisq-desktop`
applicationName = "bisq-$applicationName"
}
}
configure(project(':proto')) {
apply plugin: 'com.google.protobuf'
dependencies {
implementation "com.google.protobuf:protobuf-java:$protobufVersion"
implementation("io.grpc:grpc-protobuf:$grpcVersion") {
exclude(module: 'guava')
exclude(module: 'animal-sniffer-annotations')
}
implementation("io.grpc:grpc-stub:$grpcVersion") {
exclude(module: 'guava')
exclude(module: 'animal-sniffer-annotations')
}
implementation "com.google.guava:guava:$guavaVersion"
implementation "org.slf4j:slf4j-api:$slf4jVersion"
implementation "ch.qos.logback:logback-core:$logbackVersion"
implementation "ch.qos.logback:logback-classic:$logbackVersion"
compileOnly "org.projectlombok:lombok:$lombokVersion"
compileOnly "javax.annotation:javax.annotation-api:$javaxAnnotationVersion"
annotationProcessor "org.projectlombok:lombok:$lombokVersion"
}
sourceSets.main.java.srcDirs += [
'build/generated/source/proto/main/grpc',
'build/generated/source/proto/main/java'
]
protobuf {
protoc {
artifact = "com.google.protobuf:protoc:${protocVersion}"
}
plugins {
grpc {
artifact = "io.grpc:protoc-gen-grpc-java:${grpcVersion}"
}
}
generateProtoTasks {
all()*.plugins { grpc {} }
}
}
}
configure(project(':assets')) {
dependencies {
2019-04-22 20:14:10 +02:00
compile("com.github.bisq-network:bitcoinj:$bitcoinjVersion") {
exclude(module: 'jsr305')
exclude(module: 'slf4j-api')
exclude(module: 'guava')
exclude(module: 'protobuf-java')
exclude(module: 'bcprov-jdk15on')
2020-09-16 18:10:09 +02:00
exclude(module: 'okhttp')
exclude(module: 'okio')
}
compile "com.google.guava:guava:$guavaVersion"
compile "org.slf4j:slf4j-api:$slf4jVersion"
compile "org.apache.commons:commons-lang3:$langVersion"
}
}
configure(project(':common')) {
dependencies {
compile project(':proto')
implementation "org.jetbrains.kotlin:kotlin-stdlib-jdk8:$kotlinVersion"
compile "org.openjfx:javafx-base:$javafxVersion:$os"
compile "org.openjfx:javafx-graphics:$javafxVersion:$os"
compile "com.google.protobuf:protobuf-java:$protobufVersion"
compile "com.google.code.gson:gson:$gsonVersion"
Introduce Config as replacement for BisqEnvironment Prior to this commit, BisqExecutable has been responsible for parsing command line and config file options and BisqEnvironment has been responsible for assigning default values to those options and providing access to option values to callers throughout the codebase. This approach has worked, but at considerable costs in complexity, verbosity, and lack of any type-safety in option values. BisqEnvironment is based on the Spring Framework's Environment abstraction, which provides a great deal of flexibility in handling command line options, environment variables, and more, but also operates on the assumption that such inputs have String-based values. After having this infrastructure in place for years now, it has become evident that using Spring's Environment abstraction was both overkill for what we needed and limited us from getting the kind of concision and type saftey that we want. The Environment abstraction is by default actually too flexible. For example, Bisq does not want or need to have environment variables potentially overriding configuration file values, as this increases our attack surface and makes our threat model more complex. This is why we explicitly removed support for handling environment variables quite some time ago. The BisqEnvironment class has also organically evolved toward becoming a kind of "God object", responsible for more than just option handling. It is also, for example, responsible for tracking the status of the user's local Bitcoin node, if any. It is also responsible for writing values to the bisq.properties config file when certain ban filters arrive via the p2p network. In the commits that follow, these unrelated functions will be factored out appropriately in order to separate concerns. As a solution to these problems, this commit begins the process of eliminating BisqEnvironment in favor of a new, bespoke Config class custom-tailored to Bisq's needs. Config removes the responsibility for option parsing from BisqExecutable, and in the end provides "one-stop shopping" for all option parsing and access needs. The changes included in this commit represent a proof of concept for the Config class, where handling of a number of options has been moved from BisqEnvironment and BisqExecutable over to Config. Because the migration is only partial, both Config and BisqEnvironment are injected side-by-side into calling code that needs access to options. As the migration is completed, BisqEnvironment will be removed entirely, and only the Config object will remain. An additional benefit of the elimination of BisqEnvironment is that it will allow us to remove our dependency on the Spring Framework (with the exception of the standalone pricenode application, which is Spring-based by design). Note that while this change and those that follow it are principally a refactoring effort, certain functional changes have been introduced. For example, Bisq now supports a `--configFile` argument at the command line that functions very similarly to Bitcoin Core's `-conf` option.
2019-12-06 23:54:58 +01:00
compile "net.sf.jopt-simple:jopt-simple:$joptVersion"
compile "org.slf4j:slf4j-api:$slf4jVersion"
compile "ch.qos.logback:logback-core:$logbackVersion"
compile "ch.qos.logback:logback-classic:$logbackVersion"
compile "com.google.code.findbugs:jsr305:$findbugsVersion"
compile "com.google.guava:guava:$guavaVersion"
compile("com.google.inject:guice:$guiceVersion") {
exclude(module: 'guava')
}
2019-04-22 20:14:10 +02:00
compile("com.github.bisq-network:bitcoinj:$bitcoinjVersion") {
exclude(module: 'jsr305')
exclude(module: 'slf4j-api')
exclude(module: 'guava')
exclude(module: 'protobuf-java')
exclude(module: 'bcprov-jdk15on')
2020-09-16 18:10:09 +02:00
exclude(module: 'okhttp')
exclude(module: 'okio')
}
runtimeOnly("io.grpc:grpc-netty-shaded:$grpcVersion") {
exclude(module: 'guava')
exclude(module: 'animal-sniffer-annotations')
}
compile "org.jetbrains:annotations:$jetbrainsAnnotationsVersion"
compile "org.bouncycastle:bcpg-jdk15on:$bcVersion"
compile "commons-io:commons-io:$ioVersion"
compile "org.apache.commons:commons-lang3:$langVersion"
compileOnly "org.projectlombok:lombok:$lombokVersion"
annotationProcessor "org.projectlombok:lombok:$lombokVersion"
Introduce Config as replacement for BisqEnvironment Prior to this commit, BisqExecutable has been responsible for parsing command line and config file options and BisqEnvironment has been responsible for assigning default values to those options and providing access to option values to callers throughout the codebase. This approach has worked, but at considerable costs in complexity, verbosity, and lack of any type-safety in option values. BisqEnvironment is based on the Spring Framework's Environment abstraction, which provides a great deal of flexibility in handling command line options, environment variables, and more, but also operates on the assumption that such inputs have String-based values. After having this infrastructure in place for years now, it has become evident that using Spring's Environment abstraction was both overkill for what we needed and limited us from getting the kind of concision and type saftey that we want. The Environment abstraction is by default actually too flexible. For example, Bisq does not want or need to have environment variables potentially overriding configuration file values, as this increases our attack surface and makes our threat model more complex. This is why we explicitly removed support for handling environment variables quite some time ago. The BisqEnvironment class has also organically evolved toward becoming a kind of "God object", responsible for more than just option handling. It is also, for example, responsible for tracking the status of the user's local Bitcoin node, if any. It is also responsible for writing values to the bisq.properties config file when certain ban filters arrive via the p2p network. In the commits that follow, these unrelated functions will be factored out appropriately in order to separate concerns. As a solution to these problems, this commit begins the process of eliminating BisqEnvironment in favor of a new, bespoke Config class custom-tailored to Bisq's needs. Config removes the responsibility for option parsing from BisqExecutable, and in the end provides "one-stop shopping" for all option parsing and access needs. The changes included in this commit represent a proof of concept for the Config class, where handling of a number of options has been moved from BisqEnvironment and BisqExecutable over to Config. Because the migration is only partial, both Config and BisqEnvironment are injected side-by-side into calling code that needs access to options. As the migration is completed, BisqEnvironment will be removed entirely, and only the Config object will remain. An additional benefit of the elimination of BisqEnvironment is that it will allow us to remove our dependency on the Spring Framework (with the exception of the standalone pricenode application, which is Spring-based by design). Note that while this change and those that follow it are principally a refactoring effort, certain functional changes have been introduced. For example, Bisq now supports a `--configFile` argument at the command line that functions very similarly to Bitcoin Core's `-conf` option.
2019-12-06 23:54:58 +01:00
testCompile "org.hamcrest:hamcrest-all:$hamcrestVersion"
}
}
2018-11-04 17:18:46 +01:00
2018-11-04 17:46:03 +01:00
configure(project(':p2p')) {
dependencies {
compile project(':common')
compile("com.github.bisq-network.netlayer:tor.native:$netlayerVersion") {
2018-11-16 17:49:04 +01:00
exclude(module: 'slf4j-api')
}
compile("com.github.bisq-network.netlayer:tor.external:$netlayerVersion") {
2018-11-04 17:46:03 +01:00
exclude(module: 'slf4j-api')
}
implementation("org.apache.httpcomponents:httpclient:$httpclientVersion") {
exclude(module: 'commons-codec')
}
compile "org.fxmisc.easybind:easybind:$easybindVersion"
compileOnly "org.projectlombok:lombok:$lombokVersion"
annotationProcessor "org.projectlombok:lombok:$lombokVersion"
testCompileOnly "org.projectlombok:lombok:$lombokVersion"
testAnnotationProcessor "org.projectlombok:lombok:$lombokVersion"
2019-08-13 19:47:40 +02:00
testCompile("org.mockito:mockito-core:$mockitoVersion")
2018-11-04 17:46:03 +01:00
}
Track p2p data store files using Git LFS The large binary objects in p2p/src/main/resources/ are updated on every Bisq release with the latest network data to avoid the need for new Bisq clients to download all of this information from the network, which would easily overload seed nodes and generally bog down the client. This approach works well enough for its purposes, but comes with the significant downside of storing all of this binary data in Git history forever. The current version of these binary objects total about 65M, and they grow with every release. In aggregate, this has caused the total size of the repository to grow to 360M, making it cumbersome to clone over a low-bandwith connection, and slowing down various local Git operations. To avoid further exacerbating this problem, this commit sets these files up to be tracked via Git LFS. There's nothing we can do about the 360M of files that already exist in history, but we can ensure it doesn't grow in this unchecked way going forward. For an understanding of how Git LFS works, see the reference material at [1], and see also the sample project and README at [2]. The following command was used to track the files: $ git lfs track "p2p/src/main/resources/*BTC_MAINNET" Tracking "p2p/src/main/resources/AccountAgeWitnessStore_BTC_MAINNET" Tracking "p2p/src/main/resources/BlindVoteStore_BTC_MAINNET" Tracking "p2p/src/main/resources/DaoStateStore_BTC_MAINNET" Tracking "p2p/src/main/resources/ProposalStore_BTC_MAINNET" Tracking "p2p/src/main/resources/SignedWitnessStore_BTC_MAINNET" Tracking "p2p/src/main/resources/TradeStatistics2Store_BTC_MAINNET" We are using GitHub's built-in LFS service here, and it's important to understand that there are storage and bandwidth limits there. We have 1G total storage and 1G per month of bandwidth on the free tier. We will certainly exceed this, and so must purchase at least one "data pack" from GitHub, possibly two. One gets us to 50G storage and bandwith. In an attempt to avoid unnecessary LFS bandwidth usage, this commit also updates the Travis CI build configuration to cache Git LFS files, such that they are not re-downloaded on every CI build (see [3] and [4] below). With that out of the way, the variable determining whether we exceed the monthly limit is how many clones we have every month, and there are many, though it's not clear how many are are Travis CI and how many are users / developers. Tracking these files via LFS means that developers will need to have Git LFS installed in order to properly synchronize the files. If a developer does not have LFS installed, cloning will complete successfully and the build would complete successfully, but the app would fail when trying to actually load the p2p data store files. For this reason, the build has been updated to proactively check that the p2p data store files have been properly synchronized via LFS, and if not, the build fails with a helpful error message. The docs/build.md instructions have also been updated accordingly. It is important that we make this change now, not only to avoid growing the repository in the way described above as we have been doing now for many releases, but also because we are now considering adding yet more binary objects to the repository, as proposed at https://github.com/bisq-network/projects/issues/25. [1]: https://git-lfs.github.com [2]: https://github.com/cbeams/lfs-test [3]: https://docs-staging.travis-ci.com/user/customizing-the-build/#git-lfs [4]: https://github.com/travis-ci/travis-ci/issues/8787#issuecomment-394202791
2020-04-29 11:59:48 +02:00
processResources.doFirst {
// Sanity check that Git LFS-managed data store files have actually been sync'd.
// If they have not, e.g. because Git LFS is not installed, they will be text files
// containing a sha256 hash of the remote object, indicating we should stop the
// build and inform the user how to fix the problem.
if (file('src/main/resources/ProposalStore_BTC_MAINNET').text.contains("oid sha256:"))
throw new GradleException("p2p data store files have not been synchronized. " +
"To fix this, ensure you have Git LFS installed and run `git lfs pull`. " +
"See docs/build.md for more information.")
}
2018-11-04 17:46:03 +01:00
}
2018-11-04 17:18:46 +01:00
configure(project(':core')) {
dependencies {
compile project(':proto')
2018-11-04 17:18:46 +01:00
compile project(':assets')
compile project(':p2p')
implementation "commons-codec:commons-codec:$codecVersion"
implementation "com.google.code.gson:gson:$gsonVersion"
implementation "org.apache.httpcomponents:httpcore:$httpcoreVersion"
implementation("org.apache.httpcomponents:httpclient:$httpclientVersion") {
exclude(module: 'commons-codec')
}
compile "com.google.guava:guava:$guavaVersion"
compile("com.github.bisq-network:jsonrpc4j:$jsonrpc4jVersion") {
exclude(module: 'base64')
exclude(module: 'httpcore-nio')
2018-11-04 17:18:46 +01:00
}
compile "com.fasterxml.jackson.core:jackson-core:$jacksonVersion"
compile "com.fasterxml.jackson.core:jackson-annotations:$jacksonVersion"
compile("com.fasterxml.jackson.core:jackson-databind:$jacksonVersion") {
2018-11-04 17:18:46 +01:00
exclude(module: 'jackson-annotations')
}
implementation "com.google.protobuf:protobuf-java:$protobufVersion"
compileOnly "org.projectlombok:lombok:$lombokVersion"
annotationProcessor "org.projectlombok:lombok:$lombokVersion"
2018-11-04 17:18:46 +01:00
Introduce Config as replacement for BisqEnvironment Prior to this commit, BisqExecutable has been responsible for parsing command line and config file options and BisqEnvironment has been responsible for assigning default values to those options and providing access to option values to callers throughout the codebase. This approach has worked, but at considerable costs in complexity, verbosity, and lack of any type-safety in option values. BisqEnvironment is based on the Spring Framework's Environment abstraction, which provides a great deal of flexibility in handling command line options, environment variables, and more, but also operates on the assumption that such inputs have String-based values. After having this infrastructure in place for years now, it has become evident that using Spring's Environment abstraction was both overkill for what we needed and limited us from getting the kind of concision and type saftey that we want. The Environment abstraction is by default actually too flexible. For example, Bisq does not want or need to have environment variables potentially overriding configuration file values, as this increases our attack surface and makes our threat model more complex. This is why we explicitly removed support for handling environment variables quite some time ago. The BisqEnvironment class has also organically evolved toward becoming a kind of "God object", responsible for more than just option handling. It is also, for example, responsible for tracking the status of the user's local Bitcoin node, if any. It is also responsible for writing values to the bisq.properties config file when certain ban filters arrive via the p2p network. In the commits that follow, these unrelated functions will be factored out appropriately in order to separate concerns. As a solution to these problems, this commit begins the process of eliminating BisqEnvironment in favor of a new, bespoke Config class custom-tailored to Bisq's needs. Config removes the responsibility for option parsing from BisqExecutable, and in the end provides "one-stop shopping" for all option parsing and access needs. The changes included in this commit represent a proof of concept for the Config class, where handling of a number of options has been moved from BisqEnvironment and BisqExecutable over to Config. Because the migration is only partial, both Config and BisqEnvironment are injected side-by-side into calling code that needs access to options. As the migration is completed, BisqEnvironment will be removed entirely, and only the Config object will remain. An additional benefit of the elimination of BisqEnvironment is that it will allow us to remove our dependency on the Spring Framework (with the exception of the standalone pricenode application, which is Spring-based by design). Note that while this change and those that follow it are principally a refactoring effort, certain functional changes have been introduced. For example, Bisq now supports a `--configFile` argument at the command line that functions very similarly to Bitcoin Core's `-conf` option.
2019-12-06 23:54:58 +01:00
testCompile "org.hamcrest:hamcrest-all:$hamcrestVersion"
testCompile "org.mockito:mockito-core:$mockitoVersion"
testCompile "com.natpryce:make-it-easy:$easyVersion"
testCompileOnly "org.projectlombok:lombok:$lombokVersion"
testAnnotationProcessor "org.projectlombok:lombok:$lombokVersion"
2018-11-04 17:18:46 +01:00
}
test {
systemProperty 'jdk.attach.allowAttachSelf', true
}
}
configure(project(':cli')) {
mainClassName = 'bisq.cli.CliMain'
dependencies {
compile project(':proto')
implementation "net.sf.jopt-simple:jopt-simple:$joptVersion"
implementation "com.google.guava:guava:$guavaVersion"
implementation "com.google.protobuf:protobuf-java:$protobufVersion"
implementation("io.grpc:grpc-core:$grpcVersion") {
exclude(module: 'guava')
exclude(module: 'animal-sniffer-annotations')
}
implementation("io.grpc:grpc-stub:$grpcVersion") {
exclude(module: 'guava')
exclude(module: 'animal-sniffer-annotations')
}
runtimeOnly("io.grpc:grpc-netty-shaded:$grpcVersion") {
exclude(module: 'guava')
exclude(module: 'animal-sniffer-annotations')
}
implementation "org.slf4j:slf4j-api:$slf4jVersion"
implementation "ch.qos.logback:logback-core:$logbackVersion"
implementation "ch.qos.logback:logback-classic:$logbackVersion"
compileOnly "org.projectlombok:lombok:$lombokVersion"
annotationProcessor "org.projectlombok:lombok:$lombokVersion"
testImplementation "org.junit.jupiter:junit-jupiter-api:$jupiterVersion"
testImplementation "org.junit.jupiter:junit-jupiter-params:$jupiterVersion"
testRuntimeOnly("org.junit.jupiter:junit-jupiter-engine:$jupiterVersion")
testAnnotationProcessor "org.projectlombok:lombok:$lombokVersion"
testCompileOnly "org.projectlombok:lombok:$lombokVersion"
testRuntime "javax.annotation:javax.annotation-api:$javaxAnnotationVersion"
}
test {
useJUnitPlatform()
}
}
configure(project(':desktop')) {
apply plugin: 'com.github.johnrengelman.shadow'
apply plugin: 'witness'
apply from: '../gradle/witness/gradle-witness.gradle'
apply from: 'package/package.gradle'
2021-05-06 20:40:11 +02:00
version = '1.6.4-SNAPSHOT'
jar.manifest.attributes(
"Implementation-Title": project.name,
"Implementation-Version": version)
mainClassName = 'bisq.desktop.app.BisqAppMain'
tasks.withType(AbstractArchiveTask) {
preserveFileTimestamps = false
reproducibleFileOrder = true
}
sourceSets.main.resources.srcDirs += ['src/main/java'] // to copy fxml and css files
dependencies {
compile project(':core')
compile "net.glxn:qrgen:$qrgenVersion"
compile "de.jensd:fontawesomefx:$fontawesomefxVersion"
compile "de.jensd:fontawesomefx-commons:$fontawesomefxCommonsVersion"
compile "de.jensd:fontawesomefx-materialdesignfont:$fontawesomefxMaterialdesignfontVersion"
compile "com.google.guava:guava:$guavaVersion"
compile "com.googlecode.jcsv:jcsv:$jcsvVersion"
compile "org.openjfx:javafx-controls:$javafxVersion:$os"
compile "org.openjfx:javafx-fxml:$javafxVersion:$os"
compile "org.openjfx:javafx-swing:$javafxVersion:$os"
compile "com.jfoenix:jfoenix:$jfoenixVersion"
compileOnly "org.projectlombok:lombok:$lombokVersion"
annotationProcessor "org.projectlombok:lombok:$lombokVersion"
testCompile "org.mockito:mockito-core:$mockitoVersion"
testCompile "com.natpryce:make-it-easy:$easyVersion"
testCompileOnly "org.projectlombok:lombok:$lombokVersion"
testAnnotationProcessor "org.projectlombok:lombok:$lombokVersion"
}
2019-01-11 16:59:18 +01:00
test {
systemProperty 'jdk.attach.allowAttachSelf', true
}
}
configure(project(':monitor')) {
2018-12-11 12:20:31 +01:00
mainClassName = 'bisq.monitor.Monitor'
test {
useJUnitPlatform()
testLogging {
events "passed", "skipped", "failed"
}
}
dependencies {
2019-01-09 11:52:16 +01:00
compile project(':core')
compile "org.slf4j:slf4j-api:$slf4jVersion"
compile "ch.qos.logback:logback-core:$logbackVersion"
compile "ch.qos.logback:logback-classic:$logbackVersion"
compile "com.google.guava:guava:$guavaVersion"
2018-12-29 14:16:10 +01:00
compileOnly "org.projectlombok:lombok:$lombokVersion"
annotationProcessor "org.projectlombok:lombok:$lombokVersion"
2018-12-11 12:20:31 +01:00
testCompile "org.junit.jupiter:junit-jupiter-api:$jupiterVersion"
testCompile "org.junit.jupiter:junit-jupiter-params:$jupiterVersion"
2018-12-11 12:20:31 +01:00
testCompileOnly "org.projectlombok:lombok:$lombokVersion"
testAnnotationProcessor "org.projectlombok:lombok:$lombokVersion"
testRuntime("org.junit.jupiter:junit-jupiter-engine:$jupiterVersion")
}
}
configure(project(':pricenode')) {
apply plugin: "org.springframework.boot"
2018-11-07 08:43:03 +01:00
version = file("src/main/resources/version.txt").text.trim()
jar.manifest.attributes(
"Implementation-Title": project.name,
"Implementation-Version": version)
dependencies {
compile project(":core")
compileOnly "org.projectlombok:lombok:$lombokVersion"
annotationProcessor "org.projectlombok:lombok:$lombokVersion"
implementation "com.google.code.gson:gson:$gsonVersion"
implementation "commons-codec:commons-codec:$codecVersion"
implementation "org.apache.httpcomponents:httpcore:$httpcoreVersion"
implementation("org.apache.httpcomponents:httpclient:$httpclientVersion") {
exclude(module: 'commons-codec')
}
compile("org.knowm.xchange:xchange-bitbay:$knowmXchangeVersion")
compile("org.knowm.xchange:xchange-btcmarkets:$knowmXchangeVersion")
compile("org.knowm.xchange:xchange-binance:$knowmXchangeVersion")
compile("org.knowm.xchange:xchange-bitfinex:$knowmXchangeVersion")
compile("org.knowm.xchange:xchange-bitflyer:$knowmXchangeVersion")
compile("org.knowm.xchange:xchange-bitstamp:$knowmXchangeVersion")
compile("org.knowm.xchange:xchange-cexio:$knowmXchangeVersion")
compile("org.knowm.xchange:xchange-coinmate:$knowmXchangeVersion")
compile("org.knowm.xchange:xchange-coinmarketcap:$knowmXchangeVersion")
compile("org.knowm.xchange:xchange-coinone:$knowmXchangeVersion")
compile("org.knowm.xchange:xchange-exmo:$knowmXchangeVersion")
compile("org.knowm.xchange:xchange-hitbtc:$knowmXchangeVersion")
compile("org.knowm.xchange:xchange-huobi:$knowmXchangeVersion")
compile("org.knowm.xchange:xchange-independentreserve:$knowmXchangeVersion")
compile("org.knowm.xchange:xchange-kraken:$knowmXchangeVersion")
compile("org.knowm.xchange:xchange-luno:$knowmXchangeVersion")
compile("org.knowm.xchange:xchange-mercadobitcoin:$knowmXchangeVersion")
compile("org.knowm.xchange:xchange-paribu:$knowmXchangeVersion")
compile("org.knowm.xchange:xchange-poloniex:$knowmXchangeVersion")
compile("org.knowm.xchange:xchange-quoine:$knowmXchangeVersion")
compile("org.springframework.boot:spring-boot-starter-web:$springBootVersion")
compile("org.springframework.boot:spring-boot-starter-actuator")
testCompile "org.junit.jupiter:junit-jupiter-api:$jupiterVersion"
testCompile "org.junit.jupiter:junit-jupiter-params:$jupiterVersion"
testRuntime("org.junit.jupiter:junit-jupiter-engine:$jupiterVersion")
testCompileOnly "org.projectlombok:lombok:$lombokVersion"
testAnnotationProcessor "org.projectlombok:lombok:$lombokVersion"
}
test {
useJUnitPlatform()
// Disabled by default, since spot provider tests include connections to external API endpoints
// Can be enabled by adding -Dtest.pricenode.includeSpotProviderTests=true to the gradle command:
// ./gradlew test -Dtest.pricenode.includeSpotProviderTests=true
if (System.properties['test.pricenode.includeSpotProviderTests'] != 'true') {
project.logger.lifecycle('Pricenode: Skipping spot provider tests')
exclude 'bisq/price/spot/providers/**'
}
}
task stage {
dependsOn assemble
}
}
2018-11-04 17:58:37 +01:00
2018-11-04 17:58:37 +01:00
configure(project(':relay')) {
mainClassName = 'bisq.relay.RelayMain'
dependencies {
compile project(':common')
implementation "io.grpc:grpc-auth:$grpcVersion"
compile "com.sparkjava:spark-core:$sparkVersion"
compile "com.turo:pushy:$pushyVersion"
implementation("com.google.firebase:firebase-admin:$firebaseVersion") {
exclude(module: 'commons-logging')
exclude(module: 'httpclient')
exclude(module: 'httpcore')
exclude(module: 'grpc-auth')
}
compile "commons-codec:commons-codec:$codecVersion"
2018-11-04 17:58:37 +01:00
}
}
configure(project(':seednode')) {
apply plugin: 'com.github.johnrengelman.shadow'
mainClassName = 'bisq.seednode.SeedNodeMain'
dependencies {
compile project(':core')
compileOnly "org.projectlombok:lombok:$lombokVersion"
implementation "com.google.guava:guava:$guavaVersion"
annotationProcessor "org.projectlombok:lombok:$lombokVersion"
Introduce Config as replacement for BisqEnvironment Prior to this commit, BisqExecutable has been responsible for parsing command line and config file options and BisqEnvironment has been responsible for assigning default values to those options and providing access to option values to callers throughout the codebase. This approach has worked, but at considerable costs in complexity, verbosity, and lack of any type-safety in option values. BisqEnvironment is based on the Spring Framework's Environment abstraction, which provides a great deal of flexibility in handling command line options, environment variables, and more, but also operates on the assumption that such inputs have String-based values. After having this infrastructure in place for years now, it has become evident that using Spring's Environment abstraction was both overkill for what we needed and limited us from getting the kind of concision and type saftey that we want. The Environment abstraction is by default actually too flexible. For example, Bisq does not want or need to have environment variables potentially overriding configuration file values, as this increases our attack surface and makes our threat model more complex. This is why we explicitly removed support for handling environment variables quite some time ago. The BisqEnvironment class has also organically evolved toward becoming a kind of "God object", responsible for more than just option handling. It is also, for example, responsible for tracking the status of the user's local Bitcoin node, if any. It is also responsible for writing values to the bisq.properties config file when certain ban filters arrive via the p2p network. In the commits that follow, these unrelated functions will be factored out appropriately in order to separate concerns. As a solution to these problems, this commit begins the process of eliminating BisqEnvironment in favor of a new, bespoke Config class custom-tailored to Bisq's needs. Config removes the responsibility for option parsing from BisqExecutable, and in the end provides "one-stop shopping" for all option parsing and access needs. The changes included in this commit represent a proof of concept for the Config class, where handling of a number of options has been moved from BisqEnvironment and BisqExecutable over to Config. Because the migration is only partial, both Config and BisqEnvironment are injected side-by-side into calling code that needs access to options. As the migration is completed, BisqEnvironment will be removed entirely, and only the Config object will remain. An additional benefit of the elimination of BisqEnvironment is that it will allow us to remove our dependency on the Spring Framework (with the exception of the standalone pricenode application, which is Spring-based by design). Note that while this change and those that follow it are principally a refactoring effort, certain functional changes have been introduced. For example, Bisq now supports a `--configFile` argument at the command line that functions very similarly to Bitcoin Core's `-conf` option.
2019-12-06 23:54:58 +01:00
testCompile "org.mockito:mockito-core:$mockitoVersion"
}
}
configure(project(':statsnode')) {
mainClassName = 'bisq.statistics.StatisticsMain'
dependencies {
compile project(':core')
compileOnly "org.projectlombok:lombok:$lombokVersion"
annotationProcessor "org.projectlombok:lombok:$lombokVersion"
}
}
Introduce gRPC API proof of concept This commit introduces a new `grpc` module including the following key types: - BisqGrpcServer: The API implementation itself, along with generated gRPC Response/Reploy types defined in grpc/src/main/proto/grpc.proto. - BisqGrpcServerMain: A 'headless' / daemon-like entry point for running a Bisq node without the JavaFX desktop UI. - BisqGrpcClient: A simple, repl-style client for the API that allows the user to exercise the various endpoints as seen in the example below. In the `desktop` module, the BisqAppMain class has been modified to start a BisqGrpcServer instance if the `--desktopWithGrpcApi` option has been set to `true`. In the `core` module, a new `CoreApi` class has been introduced providing a kind of comprehensive facade for all Bisq functionality to be exposed via the RPC API. How to explore the proof of concept: 1. Run the main() method in BisqAppMain providing `--desktopWithGrpcApi=true` as a program argument or alternatively, run the main() method in BisqGrpcServerMain, where no special option is required. In either case, you'll notice the following entry in the log output: INFO bisq.grpc.BisqGrpcServer: Server started, listening on 8888 2. Now run the main() method in BisqGrpcClient. Once it has started up you are connected to the gRPC server started in step 1 above. To exercise the API, type `getVersion` via stdin and hit return. You should see the following response: INFO bisq.grpc.BisqGrpcClient - 1.2.4 Likewise, you can type `getBalance` and you'll see the following response: INFO bisq.grpc.BisqGrpcClient - 0.00 BTC and so forth for each of the implemented endpoints. For a list of implemented endpoints, see BisqGrpcServer.start(). Note once again that the code here is merely a proof of concept and should not be considered complete or production-ready in any way. In a subsequent commit, the `--desktopWithGrpcApi` option will be disabled in order to avoid any potential production use. The content of this commit is the result of squashing a number of commits originally authored by chimp1984 in the `chimp1984` fork's `grpc` branch. Co-authored-by: Chris Beams <chris@beams.io>
2019-09-18 18:39:37 +02:00
configure(project(':daemon')) {
mainClassName = 'bisq.daemon.app.BisqDaemonMain'
Introduce gRPC API proof of concept This commit introduces a new `grpc` module including the following key types: - BisqGrpcServer: The API implementation itself, along with generated gRPC Response/Reploy types defined in grpc/src/main/proto/grpc.proto. - BisqGrpcServerMain: A 'headless' / daemon-like entry point for running a Bisq node without the JavaFX desktop UI. - BisqGrpcClient: A simple, repl-style client for the API that allows the user to exercise the various endpoints as seen in the example below. In the `desktop` module, the BisqAppMain class has been modified to start a BisqGrpcServer instance if the `--desktopWithGrpcApi` option has been set to `true`. In the `core` module, a new `CoreApi` class has been introduced providing a kind of comprehensive facade for all Bisq functionality to be exposed via the RPC API. How to explore the proof of concept: 1. Run the main() method in BisqAppMain providing `--desktopWithGrpcApi=true` as a program argument or alternatively, run the main() method in BisqGrpcServerMain, where no special option is required. In either case, you'll notice the following entry in the log output: INFO bisq.grpc.BisqGrpcServer: Server started, listening on 8888 2. Now run the main() method in BisqGrpcClient. Once it has started up you are connected to the gRPC server started in step 1 above. To exercise the API, type `getVersion` via stdin and hit return. You should see the following response: INFO bisq.grpc.BisqGrpcClient - 1.2.4 Likewise, you can type `getBalance` and you'll see the following response: INFO bisq.grpc.BisqGrpcClient - 0.00 BTC and so forth for each of the implemented endpoints. For a list of implemented endpoints, see BisqGrpcServer.start(). Note once again that the code here is merely a proof of concept and should not be considered complete or production-ready in any way. In a subsequent commit, the `--desktopWithGrpcApi` option will be disabled in order to avoid any potential production use. The content of this commit is the result of squashing a number of commits originally authored by chimp1984 in the `chimp1984` fork's `grpc` branch. Co-authored-by: Chris Beams <chris@beams.io>
2019-09-18 18:39:37 +02:00
dependencies {
compile project(':core')
implementation "com.google.guava:guava:$guavaVersion"
implementation "com.google.protobuf:protobuf-java:$protobufVersion"
implementation("io.grpc:grpc-protobuf:$grpcVersion") {
exclude(module: 'guava')
exclude(module: 'animal-sniffer-annotations')
}
implementation("io.grpc:grpc-stub:$grpcVersion") {
exclude(module: 'guava')
exclude(module: 'animal-sniffer-annotations')
}
runtimeOnly("io.grpc:grpc-netty-shaded:$grpcVersion") {
exclude(module: 'guava')
exclude(module: 'animal-sniffer-annotations')
}
implementation "org.slf4j:slf4j-api:$slf4jVersion"
implementation "ch.qos.logback:logback-core:$logbackVersion"
implementation "ch.qos.logback:logback-classic:$logbackVersion"
Introduce gRPC API proof of concept This commit introduces a new `grpc` module including the following key types: - BisqGrpcServer: The API implementation itself, along with generated gRPC Response/Reploy types defined in grpc/src/main/proto/grpc.proto. - BisqGrpcServerMain: A 'headless' / daemon-like entry point for running a Bisq node without the JavaFX desktop UI. - BisqGrpcClient: A simple, repl-style client for the API that allows the user to exercise the various endpoints as seen in the example below. In the `desktop` module, the BisqAppMain class has been modified to start a BisqGrpcServer instance if the `--desktopWithGrpcApi` option has been set to `true`. In the `core` module, a new `CoreApi` class has been introduced providing a kind of comprehensive facade for all Bisq functionality to be exposed via the RPC API. How to explore the proof of concept: 1. Run the main() method in BisqAppMain providing `--desktopWithGrpcApi=true` as a program argument or alternatively, run the main() method in BisqGrpcServerMain, where no special option is required. In either case, you'll notice the following entry in the log output: INFO bisq.grpc.BisqGrpcServer: Server started, listening on 8888 2. Now run the main() method in BisqGrpcClient. Once it has started up you are connected to the gRPC server started in step 1 above. To exercise the API, type `getVersion` via stdin and hit return. You should see the following response: INFO bisq.grpc.BisqGrpcClient - 1.2.4 Likewise, you can type `getBalance` and you'll see the following response: INFO bisq.grpc.BisqGrpcClient - 0.00 BTC and so forth for each of the implemented endpoints. For a list of implemented endpoints, see BisqGrpcServer.start(). Note once again that the code here is merely a proof of concept and should not be considered complete or production-ready in any way. In a subsequent commit, the `--desktopWithGrpcApi` option will be disabled in order to avoid any potential production use. The content of this commit is the result of squashing a number of commits originally authored by chimp1984 in the `chimp1984` fork's `grpc` branch. Co-authored-by: Chris Beams <chris@beams.io>
2019-09-18 18:39:37 +02:00
compileOnly "org.projectlombok:lombok:$lombokVersion"
compileOnly "javax.annotation:javax.annotation-api:$javaxAnnotationVersion"
Introduce gRPC API proof of concept This commit introduces a new `grpc` module including the following key types: - BisqGrpcServer: The API implementation itself, along with generated gRPC Response/Reploy types defined in grpc/src/main/proto/grpc.proto. - BisqGrpcServerMain: A 'headless' / daemon-like entry point for running a Bisq node without the JavaFX desktop UI. - BisqGrpcClient: A simple, repl-style client for the API that allows the user to exercise the various endpoints as seen in the example below. In the `desktop` module, the BisqAppMain class has been modified to start a BisqGrpcServer instance if the `--desktopWithGrpcApi` option has been set to `true`. In the `core` module, a new `CoreApi` class has been introduced providing a kind of comprehensive facade for all Bisq functionality to be exposed via the RPC API. How to explore the proof of concept: 1. Run the main() method in BisqAppMain providing `--desktopWithGrpcApi=true` as a program argument or alternatively, run the main() method in BisqGrpcServerMain, where no special option is required. In either case, you'll notice the following entry in the log output: INFO bisq.grpc.BisqGrpcServer: Server started, listening on 8888 2. Now run the main() method in BisqGrpcClient. Once it has started up you are connected to the gRPC server started in step 1 above. To exercise the API, type `getVersion` via stdin and hit return. You should see the following response: INFO bisq.grpc.BisqGrpcClient - 1.2.4 Likewise, you can type `getBalance` and you'll see the following response: INFO bisq.grpc.BisqGrpcClient - 0.00 BTC and so forth for each of the implemented endpoints. For a list of implemented endpoints, see BisqGrpcServer.start(). Note once again that the code here is merely a proof of concept and should not be considered complete or production-ready in any way. In a subsequent commit, the `--desktopWithGrpcApi` option will be disabled in order to avoid any potential production use. The content of this commit is the result of squashing a number of commits originally authored by chimp1984 in the `chimp1984` fork's `grpc` branch. Co-authored-by: Chris Beams <chris@beams.io>
2019-09-18 18:39:37 +02:00
annotationProcessor "org.projectlombok:lombok:$lombokVersion"
testCompile "org.junit.jupiter:junit-jupiter-api:$jupiterVersion"
testCompile "org.junit.jupiter:junit-jupiter-params:$jupiterVersion"
testCompileOnly "org.projectlombok:lombok:$lombokVersion"
testAnnotationProcessor "org.projectlombok:lombok:$lombokVersion"
testRuntime("org.junit.jupiter:junit-jupiter-engine:$jupiterVersion")
Introduce gRPC API proof of concept This commit introduces a new `grpc` module including the following key types: - BisqGrpcServer: The API implementation itself, along with generated gRPC Response/Reploy types defined in grpc/src/main/proto/grpc.proto. - BisqGrpcServerMain: A 'headless' / daemon-like entry point for running a Bisq node without the JavaFX desktop UI. - BisqGrpcClient: A simple, repl-style client for the API that allows the user to exercise the various endpoints as seen in the example below. In the `desktop` module, the BisqAppMain class has been modified to start a BisqGrpcServer instance if the `--desktopWithGrpcApi` option has been set to `true`. In the `core` module, a new `CoreApi` class has been introduced providing a kind of comprehensive facade for all Bisq functionality to be exposed via the RPC API. How to explore the proof of concept: 1. Run the main() method in BisqAppMain providing `--desktopWithGrpcApi=true` as a program argument or alternatively, run the main() method in BisqGrpcServerMain, where no special option is required. In either case, you'll notice the following entry in the log output: INFO bisq.grpc.BisqGrpcServer: Server started, listening on 8888 2. Now run the main() method in BisqGrpcClient. Once it has started up you are connected to the gRPC server started in step 1 above. To exercise the API, type `getVersion` via stdin and hit return. You should see the following response: INFO bisq.grpc.BisqGrpcClient - 1.2.4 Likewise, you can type `getBalance` and you'll see the following response: INFO bisq.grpc.BisqGrpcClient - 0.00 BTC and so forth for each of the implemented endpoints. For a list of implemented endpoints, see BisqGrpcServer.start(). Note once again that the code here is merely a proof of concept and should not be considered complete or production-ready in any way. In a subsequent commit, the `--desktopWithGrpcApi` option will be disabled in order to avoid any potential production use. The content of this commit is the result of squashing a number of commits originally authored by chimp1984 in the `chimp1984` fork's `grpc` branch. Co-authored-by: Chris Beams <chris@beams.io>
2019-09-18 18:39:37 +02:00
}
}
configure(project(':inventory')) {
2020-10-16 06:32:37 +02:00
apply plugin: 'com.github.johnrengelman.shadow'
mainClassName = 'bisq.inventory.InventoryMonitorMain'
dependencies {
compile project(':core')
compile "com.google.guava:guava:$guavaVersion"
2020-10-15 09:23:49 +02:00
compile "com.sparkjava:spark-core:$sparkVersion"
compileOnly "org.projectlombok:lombok:$lombokVersion"
annotationProcessor "org.projectlombok:lombok:$lombokVersion"
}
}
configure(project(':apitest')) {
mainClassName = 'bisq.apitest.ApiTestMain'
// The external dao-setup.gradle file contains tasks to install and clean dao-setup
// files downloaded from
// https://github.com/bisq-network/bisq/raw/master/docs/dao-setup.zip
// These tasks are not run by the default build, but they can can be run during
// full or partial builds, or by themselves.
// To run the regular clean + build + test (non api), and install dao-setup files:
// ./gradlew clean build :apitest:installDaoSetup
// To install or re-install dao-setup file only:
// ./gradlew :apitest:installDaoSetup -x test
// To clean installed dao-setup files:
// ./gradlew :apitest:cleanDaoSetup -x test
apply from: 'dao-setup.gradle'
Move test cases into subproject test sources This change reorganizes the ':apitest' subproject to conform to a typical gradle project, where all JUnit test cases are located in the subproject's test sources folder. This makes running tests from an IDE or gradle command line interface work as expected. It will also help keep Travis CI configuration simple. To avoid interfering in normal builds, the gradle ':apitest test' task is disable by default; API tests will only run when a '-Dforce-true' system property is passed to gradle. To run API tests, run a normal build and install dao-setup files: ./gradlew clean build :apitest:installDaoSetup Then run the tests: ./gradlew :apitest:test -Dforce=true Try to avoid adding the '-Dforce=true' property to any other gradle tasks, because this enables the ':apitest test' task, and would kick off API tests before a normal build completed. The build.gradle file was modified to support this code reorg, and the 'org.junit.jupiter' dependendency was upgraded to v5.6.2 -- only in the ':apitest:test' dependency definiitions, not anywhere else in the bisq dependency definitions. The upgrade is necessary for running ordered tests. Since the scaffolding may be set up from either test cases (under the test src folder), or a class under the main src folder, some changes were made to ensure configuration paths are correct for either use case. For example, when the 'bisq-apitest' script is run from the root project directory, the current working directory is the root project directory. When gradle or an IDE is used to run @Test cases, the current working directory is :apitest subproject directory. The main source's ApiTestMain class has been stripped down, and exists only to keep the gradle build happy -- it needs a 'mainClassName' property. But this main driver does have uses. See the class comments. The other changes in this commit were made to fix style and syntax problems.
2020-07-19 21:31:46 +02:00
// We have to disable the :apitest 'test' task by default because we do not want
// to interfere with normal builds. To run JUnit tests in this subproject:
// Run a normal build and install dao-setup files first, then run:
// 'gradle :apitest:test -DrunApiTests=true'
test.enabled = System.getProperty("runApiTests") == "true"
Move test cases into subproject test sources This change reorganizes the ':apitest' subproject to conform to a typical gradle project, where all JUnit test cases are located in the subproject's test sources folder. This makes running tests from an IDE or gradle command line interface work as expected. It will also help keep Travis CI configuration simple. To avoid interfering in normal builds, the gradle ':apitest test' task is disable by default; API tests will only run when a '-Dforce-true' system property is passed to gradle. To run API tests, run a normal build and install dao-setup files: ./gradlew clean build :apitest:installDaoSetup Then run the tests: ./gradlew :apitest:test -Dforce=true Try to avoid adding the '-Dforce=true' property to any other gradle tasks, because this enables the ':apitest test' task, and would kick off API tests before a normal build completed. The build.gradle file was modified to support this code reorg, and the 'org.junit.jupiter' dependendency was upgraded to v5.6.2 -- only in the ':apitest:test' dependency definiitions, not anywhere else in the bisq dependency definitions. The upgrade is necessary for running ordered tests. Since the scaffolding may be set up from either test cases (under the test src folder), or a class under the main src folder, some changes were made to ensure configuration paths are correct for either use case. For example, when the 'bisq-apitest' script is run from the root project directory, the current working directory is the root project directory. When gradle or an IDE is used to run @Test cases, the current working directory is :apitest subproject directory. The main source's ApiTestMain class has been stripped down, and exists only to keep the gradle build happy -- it needs a 'mainClassName' property. But this main driver does have uses. See the class comments. The other changes in this commit were made to fix style and syntax problems.
2020-07-19 21:31:46 +02:00
sourceSets {
main {
resources {
exclude 'dao-setup'
exclude 'dao-setup.zip'
}
}
}
Move test cases into subproject test sources This change reorganizes the ':apitest' subproject to conform to a typical gradle project, where all JUnit test cases are located in the subproject's test sources folder. This makes running tests from an IDE or gradle command line interface work as expected. It will also help keep Travis CI configuration simple. To avoid interfering in normal builds, the gradle ':apitest test' task is disable by default; API tests will only run when a '-Dforce-true' system property is passed to gradle. To run API tests, run a normal build and install dao-setup files: ./gradlew clean build :apitest:installDaoSetup Then run the tests: ./gradlew :apitest:test -Dforce=true Try to avoid adding the '-Dforce=true' property to any other gradle tasks, because this enables the ':apitest test' task, and would kick off API tests before a normal build completed. The build.gradle file was modified to support this code reorg, and the 'org.junit.jupiter' dependendency was upgraded to v5.6.2 -- only in the ':apitest:test' dependency definiitions, not anywhere else in the bisq dependency definitions. The upgrade is necessary for running ordered tests. Since the scaffolding may be set up from either test cases (under the test src folder), or a class under the main src folder, some changes were made to ensure configuration paths are correct for either use case. For example, when the 'bisq-apitest' script is run from the root project directory, the current working directory is the root project directory. When gradle or an IDE is used to run @Test cases, the current working directory is :apitest subproject directory. The main source's ApiTestMain class has been stripped down, and exists only to keep the gradle build happy -- it needs a 'mainClassName' property. But this main driver does have uses. See the class comments. The other changes in this commit were made to fix style and syntax problems.
2020-07-19 21:31:46 +02:00
test {
useJUnitPlatform()
outputs.upToDateWhen { false } // Don't use previously cached test outputs.
Move test cases into subproject test sources This change reorganizes the ':apitest' subproject to conform to a typical gradle project, where all JUnit test cases are located in the subproject's test sources folder. This makes running tests from an IDE or gradle command line interface work as expected. It will also help keep Travis CI configuration simple. To avoid interfering in normal builds, the gradle ':apitest test' task is disable by default; API tests will only run when a '-Dforce-true' system property is passed to gradle. To run API tests, run a normal build and install dao-setup files: ./gradlew clean build :apitest:installDaoSetup Then run the tests: ./gradlew :apitest:test -Dforce=true Try to avoid adding the '-Dforce=true' property to any other gradle tasks, because this enables the ':apitest test' task, and would kick off API tests before a normal build completed. The build.gradle file was modified to support this code reorg, and the 'org.junit.jupiter' dependendency was upgraded to v5.6.2 -- only in the ':apitest:test' dependency definiitions, not anywhere else in the bisq dependency definitions. The upgrade is necessary for running ordered tests. Since the scaffolding may be set up from either test cases (under the test src folder), or a class under the main src folder, some changes were made to ensure configuration paths are correct for either use case. For example, when the 'bisq-apitest' script is run from the root project directory, the current working directory is the root project directory. When gradle or an IDE is used to run @Test cases, the current working directory is :apitest subproject directory. The main source's ApiTestMain class has been stripped down, and exists only to keep the gradle build happy -- it needs a 'mainClassName' property. But this main driver does have uses. See the class comments. The other changes in this commit were made to fix style and syntax problems.
2020-07-19 21:31:46 +02:00
testLogging {
showStackTraces = true // Show full stack traces in the console.
exceptionFormat = "full"
// Show passed & failed tests, and anything printed to stderr by the tests in the console.
// Do not show skipped tests in the console; they are shown in the html report.
events "passed", "failed", "standardError"
}
afterSuite { desc, result ->
if (!desc.parent) {
println("${result.resultType} " +
"[${result.testCount} tests, " +
"${result.successfulTestCount} passed, " +
"${result.failedTestCount} failed, " +
"${result.skippedTestCount} skipped] html report contains skipped test info")
// Show report link if all tests passed in case you want to see more detail, stdout, skipped, etc.
if (result.resultType == TestResult.ResultType.SUCCESS) {
DirectoryReport htmlReport = getReports().getHtml()
String reportUrl = new org.gradle.internal.logging.ConsoleRenderer()
.asClickableFileUrl(htmlReport.getEntryPoint())
println("REPORT " + reportUrl)
}
}
Move test cases into subproject test sources This change reorganizes the ':apitest' subproject to conform to a typical gradle project, where all JUnit test cases are located in the subproject's test sources folder. This makes running tests from an IDE or gradle command line interface work as expected. It will also help keep Travis CI configuration simple. To avoid interfering in normal builds, the gradle ':apitest test' task is disable by default; API tests will only run when a '-Dforce-true' system property is passed to gradle. To run API tests, run a normal build and install dao-setup files: ./gradlew clean build :apitest:installDaoSetup Then run the tests: ./gradlew :apitest:test -Dforce=true Try to avoid adding the '-Dforce=true' property to any other gradle tasks, because this enables the ':apitest test' task, and would kick off API tests before a normal build completed. The build.gradle file was modified to support this code reorg, and the 'org.junit.jupiter' dependendency was upgraded to v5.6.2 -- only in the ':apitest:test' dependency definiitions, not anywhere else in the bisq dependency definitions. The upgrade is necessary for running ordered tests. Since the scaffolding may be set up from either test cases (under the test src folder), or a class under the main src folder, some changes were made to ensure configuration paths are correct for either use case. For example, when the 'bisq-apitest' script is run from the root project directory, the current working directory is the root project directory. When gradle or an IDE is used to run @Test cases, the current working directory is :apitest subproject directory. The main source's ApiTestMain class has been stripped down, and exists only to keep the gradle build happy -- it needs a 'mainClassName' property. But this main driver does have uses. See the class comments. The other changes in this commit were made to fix style and syntax problems.
2020-07-19 21:31:46 +02:00
}
}
dependencies {
compile project(':proto')
compile project(':common')
compile project(':seednode')
compile project(':desktop')
compile project(':daemon')
compile project(':cli')
implementation "net.sf.jopt-simple:jopt-simple:$joptVersion"
implementation "com.google.guava:guava:$guavaVersion"
implementation "com.google.protobuf:protobuf-java:$protobufVersion"
implementation("io.grpc:grpc-protobuf:$grpcVersion") {
exclude(module: 'guava')
exclude(module: 'animal-sniffer-annotations')
}
implementation("io.grpc:grpc-stub:$grpcVersion") {
exclude(module: 'guava')
exclude(module: 'animal-sniffer-annotations')
}
implementation "org.slf4j:slf4j-api:$slf4jVersion"
implementation "ch.qos.logback:logback-core:$logbackVersion"
implementation "ch.qos.logback:logback-classic:$logbackVersion"
Move test cases into subproject test sources This change reorganizes the ':apitest' subproject to conform to a typical gradle project, where all JUnit test cases are located in the subproject's test sources folder. This makes running tests from an IDE or gradle command line interface work as expected. It will also help keep Travis CI configuration simple. To avoid interfering in normal builds, the gradle ':apitest test' task is disable by default; API tests will only run when a '-Dforce-true' system property is passed to gradle. To run API tests, run a normal build and install dao-setup files: ./gradlew clean build :apitest:installDaoSetup Then run the tests: ./gradlew :apitest:test -Dforce=true Try to avoid adding the '-Dforce=true' property to any other gradle tasks, because this enables the ':apitest test' task, and would kick off API tests before a normal build completed. The build.gradle file was modified to support this code reorg, and the 'org.junit.jupiter' dependendency was upgraded to v5.6.2 -- only in the ':apitest:test' dependency definiitions, not anywhere else in the bisq dependency definitions. The upgrade is necessary for running ordered tests. Since the scaffolding may be set up from either test cases (under the test src folder), or a class under the main src folder, some changes were made to ensure configuration paths are correct for either use case. For example, when the 'bisq-apitest' script is run from the root project directory, the current working directory is the root project directory. When gradle or an IDE is used to run @Test cases, the current working directory is :apitest subproject directory. The main source's ApiTestMain class has been stripped down, and exists only to keep the gradle build happy -- it needs a 'mainClassName' property. But this main driver does have uses. See the class comments. The other changes in this commit were made to fix style and syntax problems.
2020-07-19 21:31:46 +02:00
compileOnly "org.projectlombok:lombok:$lombokVersion"
compileOnly "javax.annotation:javax.annotation-api:$javaxAnnotationVersion"
annotationProcessor "org.projectlombok:lombok:$lombokVersion"
Move test cases into subproject test sources This change reorganizes the ':apitest' subproject to conform to a typical gradle project, where all JUnit test cases are located in the subproject's test sources folder. This makes running tests from an IDE or gradle command line interface work as expected. It will also help keep Travis CI configuration simple. To avoid interfering in normal builds, the gradle ':apitest test' task is disable by default; API tests will only run when a '-Dforce-true' system property is passed to gradle. To run API tests, run a normal build and install dao-setup files: ./gradlew clean build :apitest:installDaoSetup Then run the tests: ./gradlew :apitest:test -Dforce=true Try to avoid adding the '-Dforce=true' property to any other gradle tasks, because this enables the ':apitest test' task, and would kick off API tests before a normal build completed. The build.gradle file was modified to support this code reorg, and the 'org.junit.jupiter' dependendency was upgraded to v5.6.2 -- only in the ':apitest:test' dependency definiitions, not anywhere else in the bisq dependency definitions. The upgrade is necessary for running ordered tests. Since the scaffolding may be set up from either test cases (under the test src folder), or a class under the main src folder, some changes were made to ensure configuration paths are correct for either use case. For example, when the 'bisq-apitest' script is run from the root project directory, the current working directory is the root project directory. When gradle or an IDE is used to run @Test cases, the current working directory is :apitest subproject directory. The main source's ApiTestMain class has been stripped down, and exists only to keep the gradle build happy -- it needs a 'mainClassName' property. But this main driver does have uses. See the class comments. The other changes in this commit were made to fix style and syntax problems.
2020-07-19 21:31:46 +02:00
testImplementation "org.junit.jupiter:junit-jupiter-api:$jupiterVersion"
testImplementation "org.junit.jupiter:junit-jupiter-params:$jupiterVersion"
testRuntimeOnly("org.junit.jupiter:junit-jupiter-engine:$jupiterVersion")
Move test cases into subproject test sources This change reorganizes the ':apitest' subproject to conform to a typical gradle project, where all JUnit test cases are located in the subproject's test sources folder. This makes running tests from an IDE or gradle command line interface work as expected. It will also help keep Travis CI configuration simple. To avoid interfering in normal builds, the gradle ':apitest test' task is disable by default; API tests will only run when a '-Dforce-true' system property is passed to gradle. To run API tests, run a normal build and install dao-setup files: ./gradlew clean build :apitest:installDaoSetup Then run the tests: ./gradlew :apitest:test -Dforce=true Try to avoid adding the '-Dforce=true' property to any other gradle tasks, because this enables the ':apitest test' task, and would kick off API tests before a normal build completed. The build.gradle file was modified to support this code reorg, and the 'org.junit.jupiter' dependendency was upgraded to v5.6.2 -- only in the ':apitest:test' dependency definiitions, not anywhere else in the bisq dependency definitions. The upgrade is necessary for running ordered tests. Since the scaffolding may be set up from either test cases (under the test src folder), or a class under the main src folder, some changes were made to ensure configuration paths are correct for either use case. For example, when the 'bisq-apitest' script is run from the root project directory, the current working directory is the root project directory. When gradle or an IDE is used to run @Test cases, the current working directory is :apitest subproject directory. The main source's ApiTestMain class has been stripped down, and exists only to keep the gradle build happy -- it needs a 'mainClassName' property. But this main driver does have uses. See the class comments. The other changes in this commit were made to fix style and syntax problems.
2020-07-19 21:31:46 +02:00
testAnnotationProcessor "org.projectlombok:lombok:$lombokVersion"
testCompileOnly "org.projectlombok:lombok:$lombokVersion"
testRuntime "javax.annotation:javax.annotation-api:$javaxAnnotationVersion"
}
}