Add (init|close|release)Repository tasks for single-repo project for easier migration

[szpak]

Working on #33, I added closeAndReleaseStagingRepository (without Sonatype or something in the middle). I wonder, if we would like to have also shorter (init|close|release)Repository if just one repository is defined?

[vlsi]

Frankly speaking, I find publish and close + close a more usable set of tasks.

publish and close provides an end-user with a workable Maven repository. For instance, they can have URLs like https://oss.sonatype.org/content/repositories/orgpostgresql-1234/ which can be plugged into integration testing.
Then the user could figure out if the artifacts are good or bad.

However, if you use close and release, then it looks more like "I hope it would work, and I want to release it". If that is the intention, then it is strange why the command does not include publish.

---

In other words:

1. For trivial cases, there should be a single command like buildAndPublishAndRelsase. That should initialize the repository, it should publish all the things, close the repository (because you can't release without closing) and release it.
   Note: I'm not sure if buildAndPublishAndRelsase belongs to GN-PP. I highlight a use-case here rather than "what must be implemented in GN-PP".

2. For all the other cases, there should be buildAndPublishAndClose command + release command. The first one prepares the release candidate and verifies if Nexus validations pass. While the second release command promotes the release (which is already a closed repository).

I do not see where closeAndRelease would be useful. I am truly puzzled. Is it for the case when the user publishes artifacts to a single staging repository from different Gradle executions? (e.g. publish Linux artifacts, then Windows artifacts into a single staging repository)
If that happens, I'm sure the user would really want to validate the repository after closing. At least it would provide a way to tell if all the necessary artifacts are there at all.

@szpak , frankly speaking, all these "staging/closing/releasing" concepts were completely moot for me when I met Nexus for the first time. Now I think that the addition of a composed closeAndReleaseStagingRepository command does bring confusion, especially for those who are not sure what they need.

---

if just one repository is defined?

I see no problem with having explicit Sonatype in the command name.

I would suggest that you should refrain from creating tasks based on the number of repositories.

For instance, there's Gradle's default task like generatePomFor${publication.name}Publication. In my experience, it helps to create a task like generatePom which depends on all the generatePomFor${publication.name}Publication tasks.

That enables us to call generatePom on a root level to generate poms for all the subprojects.

Of course, your case is slightly different, however, I think a task like closeStagingRepository should mean close all the staging repositories rather than "create task only in case there's a single repository"

[szpak]

I do not see where closeAndRelease would be useful

Simple projects that do not need staging can just call one long task command instead of two (long tasks). Not everyone has requirements as yours.

That enables us to call generatePom on a root level to generate poms for all the subprojects.

It sounds very sensible. For just one Nexus configured it would behave the same as in my implementation for just one repo and for more it would (try) to (close/)release everywhere (probably not very handy in the majority of cases, but I have no practical experience with releasing to different (Nexus) repositories in one build). Thanks @visi for the idea.

[vlsi]

Simple projects that do not need staging can just call one long task command instead of two

As I said, in simple cases there's no room for close and release. There's a room for init and publish and close and release, however, I don't see when closeAndRelease is needed.

[marcphilipp]

I'm generally not a fan of adding too many "shorthand tasks" since it introduces multiple ways of achieving the same goal and might be confusing.

[szpak]

Ok. I've just applied one Vladimir's suggestion and some minor tweaks with task descriptions - #39.