These entries showed up as missing when @jmacxx ran this PR branch on
his local Linux machine under JDK 11. It is not clear why these
dependencies were required there and not elsewhere, e.g. under CI or on
my own Mac.
As mentioned in a prior commit, the upgrade to Gradle 7.x results in
many more dependency declarations in the file, many of which are
effectively duplicates. This change does not attempt to eliminate those
duplications in any clever way, but rather just tidies up and organizes
all dependency declarations by sorting them alphabetically.
CI build failed after the previous commit because the new dependency
verification file was generated on a Mac and therefore did not include
linux-specification artifact variants. This same process will need to
be done under Windows as well.
This commit removes the use of our fork of the gradle-witness plugin in
favor of Gradle's relatively new built-in dependency verification
feature [1].
The gradle/verification-metadata.xml file was produced using the
following command:
./gradlew --write-verification-metadata sha256 build
Where `build` is the usual `gradle build` command. All dependency
configurations are resolved this way, and written out to the file.
The resulting file contains 273 unique dependency declarations, as
compared to just 64 in our now-removed gradle-witness.gradle file. This
means that the coverage of dependencies verified is much more complete.
The new file contains the same sha256 checksums for each dependency as
the old file. This was manually spot-checked for a significant number of
the dependencies.
Like with gradle-witness, builds will break when dependencies are
upgraded (and now also when they are added). To fix these breakages, the
`--write-verification-metadata sha256` option must be provided to the
build. Note that new entries will be added for upgraded depedencies, but
old entries are not removed automatically from the file. These must be
removed manually.
[1]: https://docs.gradle.org/current/userguide/dependency_verification.html
This commit does what is necessary to upgrade from Gradle 6.6.1 to
7.3, including:
- generating the new Gradle wrapper
- replacing uses of 'compile' with 'implementation'
- replacing uses of 'testCompile' with 'testImplementation'
Moving from *compile to *implementation results in many more duplicated
dependency declarations throughout the file. These will be tidied up in
a subsequent commit.
Several dependencies needed to be upgraded in order to support this
change. One of them was Spring Boot, from 1.5.1 to 2.5.6. This is a
major upgrade that contained some breaking changes to the Spring Boot
Actuator. These changes required the removal of the pricenode's
/getVersion endpoint.
The Gradle Witness plugin has been disabled in this commit, because it
uses the now-removed 'compile' configuration. Use of the Witness plugin
will be removed entirely in a subsequent commit in favor of using
Gradle's new built-in dependency verification feature.
This commit refactors the first cut of the BsqSwapTradeInfo and
TradeInfo gRPC proto defs and wrappers. The change avoids duplication
of fields between BsqSwapTradeInfo and TradeInfo, and adds a
bsqSwapTradeInfo field to the old TradeInfo proto & wrapper.
The immediate goal is moving towards getting the API's 'gettrade'
method to work for both Bisq v1 trades and BSQ swap trades: the TradeInfo
proto sent to the CLI should represent either a Bisq v1 trade or a BSQ
swap trade. A mid-term term goal is to also make a new 'gettrades' method
return a List<TradeInfo> to the CLI, where items in the List<TradeInfo>
can be either v1 trades or bsq-swap trades.
- Adjust to removal of BsqSwapOfferInfo proto, use ammended OfferInfo instead.
- Remove currency-code param from all get(My)BsqSwapOffer(s) requests.
- Add new OfferCategory getAvailableOfferCategory(String offerId) service.
CLI uses this to determine which kind of gRPC request object should be
sent with a 'takeoffer' request.
- Adjust GetOffersSmokeTest to help see offer/swap-offer CLI output.
- Add core api methods to help CLI determine which type of offer to
take for a given offerId. CLI's 'takeoffer` will need to determine
which gRPC/proto request type to send to server.
- Add implemetations for getBsqSwapTradeRole(), for tradeId or trade.
- Complete BsqSwapTradeInfo impl.
- Merge BsqSwapOfferInfo fields into OfferInfo and remove BsqSwapOfferInfo.
- Change all model builders to private static class Builder.
- Add GetOfferCategory service so CLI can determine what kind of takeoffer service is to be used.
- Adjust to removal of BsqSwapOfferInfo proto.
- Call new coreApi.getRole(BsqSwapTrade) before building BsqSwapTradeInfo proto.
- Adjust GetBsqSwapOffer(s) rpc services to remove currency param.
- Adjust OfferInfo and remove BsqSwapOfferInfo.
- Add GetOfferCategory service so CLI can determine what kind of takeoffer service is to be used.
- Add comment about adding sub-message BsqSwapTradeInfo field to TradeInfo.
We shut down with a deterministic delay per seed to avoid that all seeds shut down at the
same time in case of a reorg. We use 30 sec. as distance delay between the seeds to be on the
safe side. We have 12 seeds so that's 6 minutes.
persistance is below the chain height of btc core.
With the new handling of dao state hashblocks it can be the
we have persisted the latest block up to the chain height.
Before that change we only had the last snapshot which was at least
20 blocks back persisted.
We want to avoid to get caught in a retry loop at parseBlocksOnHeadHeight
so we filter out that case just at the caller.
At parseBlocksOnHeadHeight we inline the requestChainHeadHeightAndParseBlocks
method as it is not used by other callers anymore.
This case that we request a block but our local btc core chain hight is below
that might be some edge case when we had a synced dao blocks but we btc core is
resyncing...
and FullNode
The custom implementations triggered to repeat requests
but we shut down the seed node in case of a reorg and
for desktops we request the user to shutdown.
to startPeriodicTasks.
Call that from BisqExecutable.onApplicationLaunched
We have created a non-UI timer before for the
printSystemLoadPeriodically as that was called
before the configUserThread was called (where we
define the UI timer for desktop)
Avoid that outdated donation and fee addresses are used.
In case we get an outdated donation address (RECIPIENT_BTC_ADDRESS)
we trigger a dao resync. The user get a popup for doing a restart
in that case.
For the fee address selection we do not fall back to the
RECIPIENT_BTC_ADDRESS in case no address from filter is provided
but we use the hard coded address of the current fee receiver address.
