The build now exposes two explicit ShadowJar tasks: one for the main
JavaFX client (`appJar`) and one for the headless bootstrap node
(`bootstrapNodeJar`).
Run as follows:
./gradlew appJar
-- or --
./gradlew bootstrapNodeJar
The resulting executable jar for each will be found in the `build/libs`
directory.
Thanks to @johnrengleman for his help at johnrengelman/shadow#108
Resolves#265Resolves#252
- Introduce a test-time dependency on spring-test module for access to
MockPropertySource and friends.
- Add BitsquareEnvironmentTests and test that property source precedence
works as expected, i.e. that properties supplied on the command line
have highest precedence, overriding those picked up via environment
variables, system properties, the bitsquare.properties file or any of
the other available property sources.
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.
Prior to this commit, Gradle was configured to take a -Pargs property
and split the value on whitespace, passing the result to the Gradle
application plugin's 'args' property, for example:
gradle run -Pargs="--id=foo --ip=1.1.1.1 --port=10001"
While this approach works fine when passing a single argument (i.e. when
no space delimiters are required), when multiple arguments are passed,
such as in the example above, it would result in the following error
from Gradle's own command line parser:
Unknown command-line option '--ip'
This commit simply splits the value of -Pargs on commas rather than
spaces, meaning that now multiple -Pargs values should be supplied as
follows:
gradle run -Pargs="--id=foo,--ip=1.1.1.1,--port=10001"
Resolves#264
Use `./gradlew run` to build and run Bitsquare directly.
Use `./gradlew shadowJar` to generate a portable, executable jar.
Use `./gradlew packageNative` to generate an installer binary specific
to the platform you are running on.
In the case of Windows, it is necessary to copy the two .dll files in
the `package/` directory to the directory where Bitsquare.exe is
ultimately installed.
Resolves#243
This commit applies the 'eclipse' Gradle plugin, such that .classpath,
.project and .settings files can be generated using:
./gradlew eclipse
Once the above is complete, import the project into Eclipse with the
following command:
File->Import->Existing projects into workspace
The .gitignore file has been updated accordingly.
Resolves#222
- The 'java' plugin is added implicitly by the gradle/javafx.gradle
script, so there is no longer a need to explicitly apply it.
- The 'application' plugin is no longer necessary now that we are
building native installers with the javafx plugin.
The plugin's jfx* tasks tie into the normal Gradle build lifecycle, such
that `gradle build` will now generate executables and installers
according to the OS on which the build is being run. These files are
output to the `build/distributions` directory.
Installers work as expected OS X and Linux at this point.
Windows installers do build, but a very particular configuration is
necessary on the Windows machine doing the building (this configuration
is to be documented in #109). However, even when the configuration is in
place and the MSI installer is successfully built, there is still a
fatal error at installer execution time relating to a missing
msvp100.dll file. See details at
https://bitbucket.org/shemnon/javafx-gradle/issue/43. An issue has been
created to track this from the Bitsquare side as well--see #108.
The changes made in this commit are based on on the samples at
http://bitbucket.org/shemnon/javafx-gradle and the article at
http://jaxenter.com/tutorial-a-guide-to-the-gradle-javafx-plugin-46270.html
The gradle/javafx.gradle file is copied directly from the sources in the
bitbucket repository above, as is apparently the convention (not sure
why this isn't part of the plugin itself, but that's a question to be
addressed later).
Resolves#66, #100
See #108, #109
Bitsquare depends on specific versions of BitcoinJ and TomP2P that have
not previously been published to any maven repository--until now. Based
on the 'published' branch of the bitcoinj [1] and tomp2p [2] forks under
the bitsquare organization, snapshots have been published to a temporary
repository [3] that has been made available to us by JFrog.
To be as explicit as possible, these custom-published snapshots have
had their version numbers qualified with the short hash of the commit
they were built from. So for bitcoinj, the dependency is no longer
0.12-SNAPSHOT, but 0.12.308de4e-SNAPSHOT. For TomP2P, the version has
gone from 5.0-Alpha24-SNAPSHOT to 5.0-Alpha24.805623c-SNAPSHOT.
Accordingly, these qualified versions are now reflected in the
dependency declarations in build.gradle.
This means that it is no longer necessary to build bitcoinj and tomp2p
locally in order to get up and running with Bitsquare development, and
the README has been updated accordingly. And it also means we can now
set up a Travis CI build with ease (which shall be done with #86).
Resolves#97
[1]: https://github.com/bitsquare/bitcoinj/tree/published
[2]: https://github.com/bitsquare/tomp2p/tree/published
[3]: http://partnerdemo.artifactoryonline.com/partnerdemo/libs-snapshots-local/
For creation of a self-contained executable jar.
Run:
- `./gradle executableJar`
- `java -jar ./build/libs/bitsquare.jar
Note that actually executing the jar fails with an exception from
io.bitsquare.util.AppDirectoryUtil.createDirIfNotExists. This will be
fixed later. The purpose of this commit is only to establish the
executable jar infrastructure.
- Set version at 0.1.0-SNAPSHOT, per http://semver.org practices
- Configure dependencies per existing Maven pom
- Resolve dependencies from jcenter by default, mavenLocal for custom
BitcoinJ and TomP2P binaries (which still must be built separately)
- Copy non-java files (fxml, etc) from src/main/java when processing
resources
`./gradle build` is now completes successfully.
