In case that the users blind vote list does not match the hash of the
majority we want to find if any variation of our list leads to a match
so we can still calculate the vote result.
If a updated client makes a param change request old client do not
recognize that enum. To avoid exceptions ro null pointers we fall back
to the UNDEFINED enum entry if available. As param value we show an empty
string.
Beside that issue no problems have been found so far with adding a new
param entry.
This code is no longer necessary after the recent move to JDK10, and
removing it entirely avoids spending unnecessary cycles and eliminates
the confusing "Cryptography restrictions removal not needed" message in
console output.
1. Every bond is defined by its lockup transaction. To make it easy to
track which bonds are confiscated it's easier to track them by only one
txid instead of using a map with a mix of lockup txoutputs and unlock
txoutputs.
To check if a txoutput has been confiscated it has to be checked against
the originiating lockup txid.
2. Minor fixes of naming lockedup -> lockup and comments.
The last selected payment account gets persisted so that at the next
take offer attempt that same account is selected in the combo box in
case there are multiple accounts for that currency.
It is no longer necessary to publish Maven metadata about common, core
and other submodules as they are no longer managed as separate libraries
in separate repositories. The only way these modules should be getting
referenced is from within applications in this repository such as
desktop, statsnode, etc. Essentially, we're no longer publishing our
libraries for public consumption.
- We store the bonded roles in the evaluated proposals in the dao state.
From there we can get the bonded role object as it is part of the
bonded role proposal. Though we need to take that data immutable
(next commit will handle that)
- Change type of param value from long to string for more flexibility
- Add BTC recipient address param
- Add validation, refactor param value formatter and param value parser
As take offer screen is WIP the fee display is also just a raw draft.
For the DAO state we should add a new group for the fee selection as
it is a bit lost in between the other fields...
For the upcoming API work we use java fx classes also in common (PR
is pending), so that is one reason to move that. But there was also an
issue on Linux (travis) as the platform property was not set in the
core gradle build file, but it is already defined in common.
- Change FULL_DAO_NODE option from boolean to string to be able to detect not set values
- isFullDaoNode, rpcUser and rpcPw can be set in the UI. If prog ars are
available they will overwrite the UI data.
Fix the following error:
A problem was found with the configuration of task ':common:startScripts'.
> No value has been specified for property 'mainClassName'.
- If user press cmd+t it switches to DEBUG log level for the tor
network library. If the user press it again it switch back to WARN level.
- If there is a connection startup timeout where we display the Tor
network settings popup we switch log level as well to DEBUG.
Apple disabled options do avoid App Nap in recent OSX versions.
Playing an inaudible sound marks the application for preventing to get
set to standby mode as well as App Nap mode.
The alternative to that "hack" would be to add OSX native code, but
even then it is likely only possible to prevent App Nap but not
sleep mode.
If Bisq is in App Nap mode offers cannot be taken as well the user loses
network connection and offers.
See: https://github.com/bisq-network/bisq/issues/1701
Problem: d218094 set the version to 0.7.0-SNAPSHOT, but that change
failed to produce the intended effect detailed in the commit comment.
Setting the version to a value like 0.7.0-SNAPSHOT works fine when
publishing artifacts to a local ~/.m2 repository, but JitPack has no
awareness of version metadata within pom files, and can only retreive
artifacts based on Git metadata, namely tags, branch names and commit
hashes. This means it is impossible to resolve artifacts from JitPack
with a GAV like `io.bisq.exchange:core:0.7.0-SNAPSHOT` unless there is a
branch named `0.7.0`. This is why the pull request at
bisq-network/bisq-seednode#1 failed.
Solution: JitPack supports the semantics of Maven-style `-SNAPSHOT`
versioning, and as a special case, allows for versions to be named
literally `-SNAPSHOT` with no preceding version string [1,2]. This
commit sets all Maven versions to `-SNAPSHOT`, achieving the original
effect intended by d218094. Now downstream components (like
bisq-seednode) can resolve dependencies seamlessly from JitPack or a
local ~/.m2 repo with a GAV like `io.bisq.exchange:core:-SNAPSHOT`. This
is a slightly unconventional arrangement, but should actually result in
fewer updates to pom files over time as there may in fact be no reason
to ever change this version string so long as we continue using JitPack
and avoid publication to Maven Central / JCenter or similar.
[1]: https://jitpack.io/docs/#building-with-jitpack
[2]: https://github.com/jitpack/jitpack.io/issues/351
See #1440
Problem: When resolving Bisq libraries, e.g. `core` or `network` from
JitPack for use in other components like bisq-seednode or
bisq-pricenode, we have historically, resolved them by tag or by
branchname, e.g. with GAV coordinates like `io.bisq:core:v0.6.7` or
`io.bisq:core:master`. This works well enough, but now that we are
beginning to modularize more aggressively, we want to make sure that
it's possible at any time to publish the latest snapshots of these
libraries to one's own local ~/.m2 repository such that they can be
easily resolved from downstream components without the need to push
commits to the bisq-network/exchange remote, and to wait for JitPack to
do a just-in-time build.
Solution: By updating the version value of all modules here in the
exchange repository from 0.6.7 => 0.7.0-SNAPSHOT, one can run
`mvn install` to publish the latest "snapshot" of exchange libraries to
the local ~/.m2 repository and be sure to resolve them from whatever
downstream component that they are working on. The -SNAPSHOT qualifier
ensures that no caching occurs, and that the very latest such binary
will always be used.
This new arrangement creates a situation where one can transparently
resolve these dependencies remotely from JitPack and then subsequently
resolve them locally from one's ~/.m2 repository without having to
change a line of code.
It also opens up the ability to manage all Bisq components together in a
single IDE window as if they were all in one repository, avoiding the
need even to issue a `mvn install` command to publish locally--but
that's not the main focus of this change.
Note that the change to 0.7.0 here is based on the fact that we already
planned to have the next version shipped from `master` be 0.7.0, as
there are quite a few new UI changes that probably merit the bump in
minor version. The version change also aligns well with the fact that
we're modularizing a number of components right now, and all
newly-extracted components have been jumping to v0.7.0 to indicate their
new independent status. This has been the case with bisq-seednode and
pricenode so far.
Finally, it is important to note here that the ONLY versions updated by
this change are those specific to Maven metadata and therefore artifact
management / dependency resolution. The version that the Bisq desktop
client reports in its UI and to the network in its user agent has NOT
been changed, on account of the fact that users may run Bisq from
source, and we need to think through more fully the implications of
reporting a verison like 0.7.0-SNAPSHOT in those situations. Here is a
list of files containing the old version (0.6.7) that have NOT been
updated:
- common/src/main/java/io/bisq/common/app/Version.java
- package/linux/32bitBuild.sh
- package/linux/Dockerfile
- package/osx/create_app.sh
- package/osx/finalize.sh
- package/windows/32bitBuild.bat
- package/windows/64bitBuild.bat
- package/windows/Bisq.iss
- package/linux/64bitBuild.sh
One thing we know for sure that wouldn't work here is that Bisq's
Version class currently does not support -SNAPSHOT qualifiers. It just
breaks the version string validation entirely. So we'd need to patch
that in any case if we do decide it's a good idea to let pre-release
builds report their version accurately.
Problem: The current `io.bisq` groupid does not align with the way
JitPack supports custom groupids. In order to be able to both resolve
artifacts from JitPack *and* be able to resolve the same artifacts from
one's local ~/.m2 repository, Bisq artifacts need to have the same GAV
coordinates everywhere (groupid, artifactid, version).
Solution: This commit changes all groupids from io.bisq =>
io.bisq.exchange to match the GAV coordinates produced / expected by
JitPack.
So where Bisq's core module would previously have been resolvable with
GAV coordinates `io.bisq:core:v0.6.7` it will now be resolvable as
`io.bisq.exchange:core:v0.6.7`.
Note that this change is not just to satisfy JitPack idiosyncracies, but
is actually good naming practice anyway where a multi-module build is
involved, and is arguably the way it should have been all along.
[1]: https://jitpack.io/docs/#publishing-on-jitpack
1. blocked by your internet provider or in your country - by your country
2. sent you -> send you
3. capitalized Bisq
4. I would love me some of that Bitcoin Clashic :)
