Marcin Zajączkowski

The whitelisting has disadvantage that I cannot simply test `non-blocking thread, no "markers" in the stacktrace` scenario :). In general, in production code, all of the blocking calls in non-blocking...

On the other hand, whitelisting `allowBlockingCallsInside("java.util.concurrent.ThreadPoolExecutor", "getTask");` probably not all the calls will be ignored. Update. Response to myself. GH didn't refresh the page.

> You can test it without the executor. In fact, I would not use the executor here (nor any Reactor's code) Currently I have my own `ThreadFactory` and I do...

Why do you need gradle-nexus-publish-plugin for publishing to Nexus OSS? The built-in [maven-publish](https://docs.gradle.org/current/userguide/publishing_maven.html) should be enough.

Looking at the implementation details publishing is somehow different operation than releasing. It can be done separately or with different configuration. Would you also want to have one for `publishToSonatypeAndCloseAndReleaseStagingRepository`?

> That would also be useful, perhaps it can be called `publishToSonatypeAndReleaseStagingRepository`. This is somehow inconsistent with other tasks. In the context of preceding publishing the release operation has to...

In the fully configured CI environment signing should be reliable. However, for manual releasing (I remember that at least some time ago releasing a FOSS project from CI/CD was not...

> There's no sense in running tests as a part of release. I many (smaller and/or more agile) projects if the (automatic functional/acceptance) tests pass the binaries are ready to...

As we discussed it back then, let's keep it as is and let add - along with way - the point to README explaining how to make signing to be...

Move: ``` nexusPublishing { repositories { sonatype() } } ``` from the `allprojects {}` block to the root project.