path to javapackager.exe should already be set via system %PATH% - it
could be either of %programfiles% or %programfiles(x86)% so better to
have no path prepended and use default.
Builds began failing on Travis CI with the following message:
Gtk-WARNING **: cannot open display:
This is because of tests like ViewLoaderTest, which now initialize the
JavaFX toolkit and expect a display in the process. This change starts
an Xvfb server (conveniently already available under Travis CI) in order
to provide a lightweight X11 environment and eliminate this problem.
Tests basic loading of FXML resources via the ViewLoader API. Also
introduces the FxmlResource abstraction, an interface which the
Nagivation.Items enum now implements. This simplifies the process of
testing, e.g. in this case testing a non-existent resource without
having to add a bogus value to the enum itself.
Note the @BeforeClass logic necessary to initialize the JavaFX platform.
This is necessary in order to avoid "Toolkit not initialized"
exceptions. See http://stackoverflow.com/q/11385604 for details.
Prior to this change, all callers of ViewLoader#load were forced to
handle the (checked) IOException declared by the #load method signature.
This resulted in a significant amount of duplicate handling logic where
nothing more than logging the error occured.
Failing to load a view represents a catastrophic error in the
application; i.e. it is not something that can be handled in any way
other than shutting the application down, fixing what is broken and
restarting the application. For this reason, any IOException raised
within ViewLoader#load is now caught, wrapped and re-thrown as an
(unchecked) RuntimeException. This will be handled by the platform's
UncaughtExceptionHandler, and a dialog will be raised to inform the user
that a fatal error has occured.
As a result all try/catch blocks around calls to ViewLoader#load have
now been removed, making for tighter, more readable, and easier to test
code.
In the future, the distinction between errors that are programmatically
recoverable and those that are catastrophic (typically developer errors)
will be used to determine whether methods in the Bitsquare API throw
checked or unchecked exceptions.
