[bisq-network/bisq] Transitive dependencies creating version conflicts & missing jar verification (#4086)

[Stan]

<!--
   SUPPORT REQUESTS: This is for reporting bugs in the Bisq app.
   If you have a support request, please join #support on Bisq's
   Keybase team at https://keybase.io/team/Bisq
-->

### Description

The gradle build needs to be more strict about excluding transitive dependencies that create version conflicts.  (This implies some dependencies might need to be upgraded, and some even downgraded, to align versions of direct and transitive dependencies.)

#### Version

Commit 17bb7b4

### Steps to reproduce

Build Bisq and see multiple versions of some jars in the lib dir.

### Expected behaviour

There should not be any version conflicts, and every jar needs to be verified by the gradle-witness.gradle file.

### Actual behaviour

There are several transitive dependencies downloaded during the build that conflict with direct dependencies specified in gradle.build, and they are not being verified by gradle-witness.  For example, here are duplicate jars with the letters 'grpc' in their name:

    grpc-context-1.10.1.jar
    grpc-context-1.25.0.jar
    grpc-core-1.10.1.jar
    grpc-core-1.25.0.jar
    grpc-netty-shaded-1.10.1.jar
    grpc-netty-shaded-1.25.0.jar
    grpc-protobuf-1.10.1.jar
    grpc-protobuf-1.25.0.jar
    grpc-protobuf-lite-1.10.1.jar
    grpc-protobuf-lite-1.25.0.jar
    grpc-stub-1.10.1.jar
    grpc-stub-1.25.0.jar
    opencensus-contrib-grpc-metrics-0.11.0.jar
    opencensus-contrib-grpc-metrics-0.21.0.jar


This may not be an urgent problem because the latest jar is loaded at runtime. However, that also means that a transitive dependency with a larger version than is specified in the build file is loaded, not the jar which has passed gradle witness verification.  For example:  the build file specifies

    slf4jVersion = '1.7.22'

but 

    lsof -Pan -p $(pgrep -f BisqAppMain)        ( on linux )

shows me that the transitive dependency slf4j-api-1.7.25.jar is being loaded instead.

Maybe building the shipped, shaded jar eliminates most of this problem, but it's already eaten a good bit of my time trying to figure out why the grpc jar version conflicts I described above exist.


-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/bisq-network/bisq/issues/4086
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.bisq.network/pipermail/bisq-github/attachments/20200321/16bca979/attachment.html>