This change avoids the as-yet unexplained resolution errors we've been
seeing out of JCenter today, which look like the following:
Could not resolve all files for configuration ':monitor:compileClass
> Could not resolve net.gpedro.integrations.slack:slack-webhook:1.1.
Required by:
project :monitor
> Could not resolve net.gpedro.integrations.slack:slack-webhook:1
> Could not get resource 'http://jcenter.bintray.com/net/gpedr
> Could not HEAD 'http://jcenter.bintray.com/net/gpedro/int
> sun.security.validator.ValidatorException: PKIX path b
For full context, see the Travis CI build failure at
https://travis-ci.org/bisq-network/bisq/builds/451786384#L678-L679.
It is assumed this is an issue on the JCenter side, e.g. something to do
with the interaction of JCenter servers and their SSL implementation
when accessed under OpenJDK 10 and its TrustStore implementation. This
specific failure does not occur under Oracle JDK 11, but other
dependencies do fail in a similar but non-deterministic fashion. In any
case, resolving project dependencies from Maven Central solves the
problem in the meantime.
See also https://github.com/gradle/gradle/issues/6630.
Owners are space-separated, not comma-separated. It is presumed that
this syntax error is why reviews have not been being suggested for
assignment as expected.
Previously, when assets was managed as a separate library and
repository, its Javadoc was published via Jitpack and linked to from the
documentation at https://bisq.network. This is no longer the case, and
therefore building the Javadoc jar is no longer necessary.
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.
- Move gradle-witness.jar to top level
- Extract gradle-witness.gradle build file to top level
Moving these files out of the gradle/ dir and the main build file to the
top level of the repository calls them out and makes their presence and
function more obvious. It also removes a lot of noise from the main
build file.
