bisq/build.gradle

536 lines
20 KiB
Groovy
Raw Normal View History

buildscript {
repositories {
jcenter()
}
dependencies {
classpath 'com.google.protobuf:protobuf-gradle-plugin:0.8.10'
classpath 'com.google.gradle:osdetector-gradle-plugin:1.6.0'
classpath 'com.github.jengelman.gradle.plugins: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.56'
bitcoinjVersion = 'a88d36d'
2019-09-02 15:59:55 +02:00
btcdCli4jVersion = '975ff5d4'
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 = '20.0'
guiceVersion = '4.2.2'
hamcrestVersion = '1.3'
httpclientVersion = '4.5.12'
httpcoreVersion = '4.4.13'
ioVersion = '2.6'
jacksonVersion = '2.8.10'
javafxVersion = '11.0.2'
javaxAnnotationVersion = '1.2'
jcsvVersion = '1.4.0'
jetbrainsAnnotationsVersion = '13.0'
jfoenixVersion = '9.0.6'
joptVersion = '5.0.4'
jsonsimpleVersion = '1.1.1'
junitVersion = '4.12'
jupiterVersion = '5.3.2'
kotlinVersion = '1.3.41'
knowmXchangeVersion = '4.3.3'
langVersion = '3.8'
logbackVersion = '1.1.11'
loggingVersion = '1.2'
lombokVersion = '1.18.2'
2019-08-13 17:47:53 +02:00
mockitoVersion = '3.0.0'
netlayerVersion = '0.6.7'
protobufVersion = '3.10.0'
protocVersion = protobufVersion
pushyVersion = '0.13.2'
qrgenVersion = '1.3'
sarxosVersion = '0.3.12'
slf4jVersion = '1.7.25'
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')]) {
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 (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 {
compile("com.github.bisq-network.bitcoinj:bitcoinj-core:$bitcoinjVersion") {
exclude(module: 'jsr305')
exclude(module: 'slf4j-api')
exclude(module: 'guava')
exclude(module: 'protobuf-java')
}
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')
}
compile("com.github.bisq-network.bitcoinj:bitcoinj-core:$bitcoinjVersion") {
exclude(module: 'jsr305')
exclude(module: 'slf4j-api')
exclude(module: 'guava')
exclude(module: 'protobuf-java')
}
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.JesusMcCloud.netlayer:tor.native:$netlayerVersion") {
2018-11-16 17:49:04 +01:00
exclude(module: 'slf4j-api')
}
compile("com.github.JesusMcCloud.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
}
}
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("network.bisq.btcd-cli4j:btcd-cli4j-core:$btcdCli4jVersion") {
2018-11-04 17:18:46 +01:00
exclude(module: 'slf4j-api')
exclude(module: 'httpclient')
exclude(module: 'commons-lang3')
exclude(module: 'jackson-core')
exclude(module: 'jackson-annotations')
exclude(module: 'jackson-databind')
}
compile("network.bisq.btcd-cli4j:btcd-cli4j-daemon:$btcdCli4jVersion") {
2018-11-04 17:18:46 +01:00
exclude(module: 'slf4j-api')
exclude(module: 'httpclient')
exclude(module: 'commons-lang3')
exclude(module: 'jackson-core')
exclude(module: 'jackson-annotations')
exclude(module: 'jackson-databind')
}
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"
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')
}
compileOnly "javax.annotation:javax.annotation-api:$javaxAnnotationVersion"
runtimeOnly("io.grpc:grpc-netty-shaded:$grpcVersion") {
exclude(module: 'guava')
exclude(module: 'animal-sniffer-annotations')
}
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.app.BisqCliMain'
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"
}
}
configure(project(':desktop')) {
apply plugin: 'com.github.johnrengelman.shadow'
apply plugin: 'witness'
apply from: '../gradle/witness/gradle-witness.gradle'
2020-04-08 22:59:10 +02:00
version = '1.3.1-SNAPSHOT'
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 "com.github.sarxos:webcam-capture:$sarxosVersion"
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")
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-bitcoinaverage:$knowmXchangeVersion")
compile("org.knowm.xchange:xchange-coinmarketcap:$knowmXchangeVersion")
compile("org.knowm.xchange:xchange-poloniex:$knowmXchangeVersion")
compile("org.springframework.boot:spring-boot-starter-web:$springBootVersion")
compile("org.springframework.boot:spring-boot-starter-actuator")
}
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')
}
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"
}
}