HDDS-11925. Fix deploy step in Release Manager guide

[adoroszlai]

What changes were proposed in this pull request?

mvn deploy rebuilds the project, as it executes all phases of the default lifecycle up to deploy. Not only is it unnecessary, it causes jars to be different between Maven repo and binary tarball.

mvn deploy:deploy just executes Maven Deploy Plugin's deploy task, which is to upload artifacts to the remote repository.

Flags -Psign -DskipTests -Dbuildhelper.skipAttach can be removed, since they are specific to other plugins, which would (before this change) be executed in various lifecycle phases.

Skipping :ozone-dist seems to be unnecessary, too. I don't see why we should not include it in the Maven repo.

https://issues.apache.org/jira/browse/HDDS-11925

How was this patch tested?

Will be tested during next release. (Tested similar change in Ratis, see apache/ratis#1188.)

[errose28]

Thanks for looking into this @adoroszlai. I'm also not sure why ozone-dist was skipped originally. Maybe this was an attempt to re-use those artifacts from the original build?

Is there an extra verification step we can add to the release guide to make sure something like this gets caught during the release cycle? For example if some part of the original build is accidentally cleaned and the mvn deploy:deploy uploads partial artifacts. Maybe after uploading to nexus we can have the manager download the artifacts from both sources and check if they match.

[adoroszlai]

Sorry, it turns out that deploy:deploy is not enough in itself. I assumed it would deploy artifacts from local build/repo to remote one. It works fine for modules with packaging=pom, but fails for other types of packaging (jar, in our case). I will need to further refine the steps.