Vladimir Sitnikov

@ComBatVision , you could use `useStaging.set(true)`

@szpak , it looks like it is worth fixing code at https://github.com/gradle-nexus/publish-plugin/blob/0aea95597e2eeaf9275a286254894bad29b3d1e1/src/main/kotlin/io/github/gradlenexus/publishplugin/NexusPublishPlugin.kt#L208-L213 In other words, the current code uses `useStaging` for `snapshot vs release` decision, however, I would suggest that...

I don't think it should be the default behavior. I guess sign task fails less often than `compileJava`

> long and generating side effects Starting `initialize*StagingRepository` early enables us to have concurrency, so the repository is ready by the time artifacts are ready for deployment.

`initialize*StagingRepository` can fail as well. If it fails, then the other tasks make little sense. > In my projects usually tests takes the biggest amount of time I do not...

I use the same approach for non-Apache projects as well. In those cases, the step `2` is just skipped (CI validates commits anyway, so running tests during release does not...

> noticeable long `org.gradle.parallel=true` solves that, doesn't it? > and generating side effects - a new staging repository in Nexus What's the problem with that? The repository can easily be...

>shouldRunAfter(tasks.withType()). Somebody might say: don't bother me asking the pgp password if Nexus repository is not available anyway.

> I still think preparing the artifacts to be uploaded locally before creating a remote resource is sensible. `sign` is not the only task that `prepares artifacts`. Artifacts can be...

I believe https://github.com/gradle-nexus/publish-plugin/pull/145 adds a foundation for the feature. In other words, firstly you coould create a staging repo (e.g. when publishing the first project), then you use `findStagingRepo` task...