bisq/build.gradle

100 lines
3.1 KiB
Groovy
Raw Normal View History

import org.apache.tools.ant.filters.ReplaceTokens
import org.apache.tools.ant.taskdefs.condition.Os
plugins {
2014-11-07 16:04:56 +01:00
id "com.github.johnrengelman.shadow" version "1.1.2"
id "com.github.kt3k.coveralls" version "2.0.1x"
}
apply plugin: 'java'
apply plugin: 'eclipse'
apply plugin: 'application'
apply plugin: 'jacoco'
wrapper.gradleVersion = '2.1'
version = '0.1.0-SNAPSHOT'
sourceCompatibility = 1.8
sourceSets.main.resources.srcDirs += 'src/main/java'
Overhaul property management and main class infrastructure Use of the Spring Environment ----------------------------- This change replaces the use of the argparse4j library and basic Properties objects with the Spring Framework's Environment abstraction. The Environment allows for managing any number of 'property sources' in a hierarchical fashion, such that a call to `environment.getProperty("someKey")` iterates through an ordered set of property sources, returning the first value associated with the given key. BitsquareEnvironment, introduced in this commit, eliminates the functionality previously present in ConfigLoader, modeling the bitsquare.conf and bitsquare.properties files as Spring Resource objects, and in turn creating ResourcePropertySources out of them. These custom property sources are combined with standard property sources based on system environment variables and Java system properties as well as a property source based on the command-line arguments passed to a Bitsquare application to form a unified, one-stop configuration hierarchy. For example, let's say a Bitsquare user wishes to customize the port that his Bitsquare application listens on. The simplest approach (assuming the user is comfortable with the command line), would be the following: java -jar bitsquare.jar --port=1234 where '1234' is the custom port of choice. This is convenient enough for one-off experimentation, but if the user wishes to make this a permanent arrangement, he may want to add a `port=1234` entry to his {bitsquare_app_dir}/bitsquare.conf file. Alternatively, the user may wish to specify the port value as an environment variable, e.g.: PORT=1234 java -jar bitsquare.jar or with a JVM system property, e.g.: java -jar -DPORT=1234 bitsquare.jar With BitsquareEnvironment, and its customized set of PropertySources in place, the value of the port property may be specified in any of the ways described above, and it is all handled in a unified way. Restructuring of *Main classes ------------------------------ This commit also introduces significant changes to the structure of executable Bitsquare applications. For example, prior to this change, the io.bitsquare.app.gui.Main class was responsible for being both a JavaFX Application and a standard Java main class. Now, however, these concerns have been renamed and separated. BitsquareApp is the JavaFX Application, and BitsquareAppMain is the Java main class. Likewise, BootstrapNode has been broken out into BootstrapNode and BootstrapNodeMain. A common base class for the *Main classes has been extracted, named BitsquareExecutable, which creates a template for option parsing, environment creation, and ultimately application execution that applies both to the BootstrapNode and BitsquareApp cases. Improved help text ------------------ With the removal of argparse4j and the introduction of JOpt for argument parsing, the application's help text has been improved. Use --help to display this text, where you'll see information about default values, etc. To do this easily from the Gradle build, run any of the following commands: # Display help text ./gradlew run -Pargs="--help" # Qualify the application name as "Bitsquare-Alice" ./gradlew run -Pargs="--appName=Alice" # Customize the port ./gradlew run -Pargs="--port=7377" Renaming of FatalException -------------------------- Finally, the exception formerly known as io.bitsquare.gui.FatalException has been moved up a package and generalized to io.bitsquare.BitsquareException, as it is now used more widely.
2014-11-10 15:48:27 +01:00
mainClassName = "io.bitsquare.app.gui.BitsquareAppMain"
run {
2014-11-07 16:04:56 +01:00
if (project.hasProperty('args')) {
args project.args.split(',')
}
}
processResources {
from(sourceSets.main.resources.srcDirs) {
include '**/*.properties'
2014-11-12 11:11:59 +01:00
filter(ReplaceTokens, tokens: ['app.version': project.version])
}
}
repositories {
jcenter()
maven { url 'http://partnerdemo.artifactoryonline.com/partnerdemo/libs-snapshots-local' }
}
dependencies {
2014-11-17 18:57:58 +01:00
compile 'org.bitcoinj:bitcoinj-core:0.12.2'
2014-11-17 17:40:22 +01:00
compile 'net.tomp2p:tomp2p-all:5.0-Alpha.8f1cafb-SNAPSHOT'
Improve service initialization coordination using rx.Observable This change introduces the use of RxJava's Observable [1] to redesign how we work with non-deterministic and/or event-based information, such as: connecting to peer-to-peer infrastructure, synchronizing the bitcoin blockchain, and so on. Prior to this commit, these activities were initiated in methods like WalletService#initialize and TomP2PMessageService#init. These methods accepted 'listener' interfaces, and these listeners' callback methods would be invoked whenever work progressed, completed, or failed. This approach required significant coordination logic, which, prior to this commit, was found primarily in MainModel#initBackend. A primary goal of the logic found here was to determine when the backend was "ready". This state was represented in MainModel's `backendReady` field, which would be set to true once the following three conditions were satisfied: 1. the message service had finished initialization 2. the wallet service had finished initialization, and 3. the blockchain synchronization had reached 100% Monitoring these three states was complex, and required hard-to-follow conditional logic spread across a number of locations in the code. In any case, however, once these three conditions were satisfied and backendReady's value was set to true, a listener on the backendReady field (in MainViewCB#doInitialize) would then populate combo boxes and pending trade counts in the main view and cause the splash screen to fade out, rendering the application ready for user interaction. The introduction of rx.Observable is designed to achieve the same show-the-splash-screen-until-everything-is-ready functionality described above, without the complex monitoring, conditional logic and nested callbacks. This is achieved by modeling each process as an Observable stream of events. Observables in RxJava can emit any number of events, and can complete either normally or with an error. These observables may be 'subscribed' to by any number of subscribers, and events emitted can be acted upon by instructing the subscriber what to do `onNext`, `onCompleted`, and `onError`. So for example WalletService now exposes an Observable<Double> called bootstrapState. This Observable is subscribed to in MainModel#initBackend in such a way that every time it emits a new double value (i.e. a new percentage), the various bootstrap state text labels and progress indicators are updated accordingly. Where it gets really interesting, however, is when Observables are combined. The primary complexity described above is coordinating the fading out of the splash screen with the completed initialization of all backend services. As can now be seen in MainModel#initBackend, the wallet service and message service Observables are simply "merged" into a single observable and returned. From the MainViewCB side, this "single backend observable" is subscribed to and, when it completes (i.e. when all the underlying Observables complete), then combo boxes and pending trade counts are populated and the splash screen is faded out. Understanding RxJava, Observables, and the principles of "Functional Reactive Programming" takes time. It is a paradigm shift in dealing with concurrency and non-determinism, but one that ultimately rewards those who take the time. In the end, I believe it's use will result in a significantly more concise and robust internal architecture for Bitsquare, and using RxJava's lightweight, well-adopted and infrastructure-agnostic API leaves us open to using Akka or other more sophisticated infrastructure later without tying ourselves to those specific APIs (because virtually anything can be modeled as an Observable). Achieve these benifits means that core committers will need to understand how RxJava works, how to think about it, and how to design using it. I have spent the better part of the last week getting to know it, and I am certainly still learning. I can recommend many resources to aid in this process, but having gone through it myself, I recommend that everyone read at least [1] and [2] first. [1]: https://github.com/ReactiveX/RxJava/wiki/Observable [2]: [The introduction to Reactive Programming you've been missing](https://gist.github.com/staltz/868e7e9bc2a7b8c1f754)
2014-11-18 11:57:50 +01:00
compile 'io.reactivex:rxjava:1.0.0-rc.12'
Overhaul property management and main class infrastructure Use of the Spring Environment ----------------------------- This change replaces the use of the argparse4j library and basic Properties objects with the Spring Framework's Environment abstraction. The Environment allows for managing any number of 'property sources' in a hierarchical fashion, such that a call to `environment.getProperty("someKey")` iterates through an ordered set of property sources, returning the first value associated with the given key. BitsquareEnvironment, introduced in this commit, eliminates the functionality previously present in ConfigLoader, modeling the bitsquare.conf and bitsquare.properties files as Spring Resource objects, and in turn creating ResourcePropertySources out of them. These custom property sources are combined with standard property sources based on system environment variables and Java system properties as well as a property source based on the command-line arguments passed to a Bitsquare application to form a unified, one-stop configuration hierarchy. For example, let's say a Bitsquare user wishes to customize the port that his Bitsquare application listens on. The simplest approach (assuming the user is comfortable with the command line), would be the following: java -jar bitsquare.jar --port=1234 where '1234' is the custom port of choice. This is convenient enough for one-off experimentation, but if the user wishes to make this a permanent arrangement, he may want to add a `port=1234` entry to his {bitsquare_app_dir}/bitsquare.conf file. Alternatively, the user may wish to specify the port value as an environment variable, e.g.: PORT=1234 java -jar bitsquare.jar or with a JVM system property, e.g.: java -jar -DPORT=1234 bitsquare.jar With BitsquareEnvironment, and its customized set of PropertySources in place, the value of the port property may be specified in any of the ways described above, and it is all handled in a unified way. Restructuring of *Main classes ------------------------------ This commit also introduces significant changes to the structure of executable Bitsquare applications. For example, prior to this change, the io.bitsquare.app.gui.Main class was responsible for being both a JavaFX Application and a standard Java main class. Now, however, these concerns have been renamed and separated. BitsquareApp is the JavaFX Application, and BitsquareAppMain is the Java main class. Likewise, BootstrapNode has been broken out into BootstrapNode and BootstrapNodeMain. A common base class for the *Main classes has been extracted, named BitsquareExecutable, which creates a template for option parsing, environment creation, and ultimately application execution that applies both to the BootstrapNode and BitsquareApp cases. Improved help text ------------------ With the removal of argparse4j and the introduction of JOpt for argument parsing, the application's help text has been improved. Use --help to display this text, where you'll see information about default values, etc. To do this easily from the Gradle build, run any of the following commands: # Display help text ./gradlew run -Pargs="--help" # Qualify the application name as "Bitsquare-Alice" ./gradlew run -Pargs="--appName=Alice" # Customize the port ./gradlew run -Pargs="--port=7377" Renaming of FatalException -------------------------- Finally, the exception formerly known as io.bitsquare.gui.FatalException has been moved up a package and generalized to io.bitsquare.BitsquareException, as it is now used more widely.
2014-11-10 15:48:27 +01:00
compile 'org.springframework:spring-core:4.1.1.RELEASE'
compile 'net.sf.jopt-simple:jopt-simple:4.8'
compile 'org.slf4j:slf4j-api:1.7.7'
compile 'ch.qos.logback:logback-core:1.1.2'
compile 'ch.qos.logback:logback-classic:1.1.2'
compile 'com.google.inject:guice:3.0'
compile 'com.google.guava:guava:16.0.1'
compile 'com.google.code.gson:gson:2.2.4'
compile 'org.controlsfx:controlsfx:8.0.6_20'
compile 'de.jensd:fontawesomefx:8.0.0'
compile 'net.glxn:qrgen:1.3'
compile 'com.google.code.findbugs:jsr305:2.0.3'
compile 'net.jcip:jcip-annotations:1.0'
compile 'org.jetbrains:annotations:13.0'
compile 'eu.hansolo.enzo:Enzo:0.1.5'
testCompile 'junit:junit:4.11'
testCompile 'org.springframework:spring-test:4.1.1.RELEASE'
}
shadowJar.classifier = 'app'
2014-11-07 16:04:56 +01:00
task packageNative(type: Exec, dependsOn: shadowJar) {
if (Os.isFamily(Os.FAMILY_MAC))
executable "${project.rootDir}/package/mac.sh"
else if (Os.isFamily(Os.FAMILY_UNIX))
executable "${project.rootDir}/package/linux.sh"
else if (Os.isFamily(Os.FAMILY_WINDOWS))
executable "${project.rootDir}/package/windows.bat"
else
throw new GradleException("Unsupported OS: " + System.properties['os.name'])
args project.version, shadowJar.archivePath, mainClassName
}
task appJar(dependsOn: shadowJar) {
group = "shadow"
description = "Builds a Bitsquare client UI executable jar"
}
task bootstrapNodeJar(type: com.github.jengelman.gradle.plugins.shadow.tasks.ShadowJar) {
group = "shadow"
description = "Builds a Bitsquare bootstrap node executable jar"
manifest.attributes 'Main-Class': 'io.bitsquare.app.cli.BootstrapNodeMain'
classifier = 'bootstrapNode'
from(project.convention.getPlugin(JavaPluginConvention).sourceSets.main.output)
configurations = [project.configurations.runtime]
exclude('META-INF/INDEX.LIST', 'META-INF/*.SF', 'META-INF/*.DSA', 'META-INF/*.RSA')
}
jacocoTestReport {
reports {
xml.enabled = true
html.enabled = true
}
}