Move configuration out of sonatype-oss-release to enable it by default (except for maven-gpg-plugin), and update related configuration as necessary.

[copybara-service]

Move configuration out of sonatype-oss-release to enable it by default (except for maven-gpg-plugin), and update related configuration as necessary.

...as contemplated in cl/788538710 and elsewhere.

(Background: We carried much or all of the sonatype-oss-release configuration over from the old oss-parent in changes like cl/492304151.)

This (I hope) accomplished two classes of goals:

• By enabling[*] central-publishing-maven-plugin by default, we enable it even for snapshot deployment. Advantages:
  • It lets the plugin automatically disable maven-deploy-plugin. (Compare cl/805973207 for Truth.) And that allows us to remove the configuration of https://central.sonatype.com/repository/maven-snapshots, which isn't needed by central-publishing-maven-plugin but which has been required by maven-deploy-plugin, which has no default. (Compare cl/805870501 for Truth.)
  • It causes us to begin deploying snapshots through the new Central system.
    • To make that work, we need to set server-id to central, not sonatype-central-staging, since central-publishing-maven-plugin uses a different ID than we had maven-deploy-plugin set up to use. (Compare cl/807814773 for Truth.) Since central is also what is used for non-snapshot releases, we could view this is a baby step toward performing non-snapshot releases on GitHub CI someday.
• It ensures that non-release builds also run some plugins and/or use the versions of those plugins that we have requested. (For some projects, we've already been running these plugins, or we've at least kept versions consistent because we use dependencyManagement or other explicit versions.) Advantages and fallout:
  • We now get coverage for Javadoc during CI. (We've wanted this before. We went so far as to implement it for Truth in cl/509829752, and I've wanted it multiple times for Compile-Testing: cl/494805776, cl/802247571.) This change led to errors for Compile-Testing (again!) under JDK 8, so I fixed those by making the --add-exports configuration conditional.
  • We need to make a change to some of our CI configurations: Our snapshot-publishing builds request Javadoc and sources explicitly at the command line (with mvn source:jar javadoc:jar deploy). With this CL's changes, Maven would try to build Javadoc and sources twice—once for the command-line request and once for the new configuration we have. The fix for that is to stop making the explicit request. (Compare cl/807772725 for Truth, somewhat cl/572327204 for Guava, and maybe sorta kinda cl/536746714 for jimfs.)
  • We address the following warning, which Run maven BestPractices guava#7961 had proposed to address another way but for which I'd merely added a TODO in cl/804600714:

    [WARNING] Some problems were encountered while building the effective model for com.google.guava:guava-tests:jar:999.0.0-HEAD-jre-SNAPSHOT
    [WARNING] 'build.plugins.plugin.version' for org.sonatype.central:central-publishing-maven-plugin is missing. @ line 103, column 15
    [WARNING]
    [WARNING] It is highly recommended to fix these problems because they threaten the stability of your build.
    [WARNING]
    [WARNING] For this reason, future Maven versions might no longer support building such malformed projects.
    

[*] "Enabling" may or may not be the right word. The central-publishing-maven-plugin plugin still doesn't run unless someone actually runs mvn deploy. The only difference in output that that plugin change causes for a typical build is this, which I assume is related to its usage of <extensions>true</extensions>:

[INFO] Inspecting build with total of 6 modules
[INFO] Installing Central Publishing features

I left maven-gpg-plugin alone because we don't want to request that users enter their signing keys during snapshot deployment, let alone during normal builds. Another option would be to move it out of the profile but to disable it by default, with the profile becoming responsible for undoing the disablement. (Or we could stop using a profile entirely in favor of passing a flag to set a property to do the same.) That would theoretically be nice because it helps with the "same version number" goal discussed above. But given that I never recall having run maven-gpg-plugin outside a release setting, I doubt that that matters in practice.

(If we're lucky, this CL's changes to Auto specifically might be enough to deal with google/auto#1965.)

Plus: I removed some redundant declarations of <groupId>org.apache.maven.plugins</groupId>, which is the default for plugins. (We had been including it inconsistently.) Compare cl/793718324.

Finally: In Guava, I removed a "Guava Documentation Site" entry. This was added back in cl/29254221, but I can't immediately figure out why, and I see no other references to its guava-site in either the main or gh-pages branch of our repo, nor anywhere internal to Google. I'm hoping that it's at least become unnecessary in the past decade-plus. (The changes in this CL at least have no effect on the jars that we produce as output.)

Bonus Maven curiosity: I noticed that we have been getting a Javadoc warning:

[WARNING] Javadoc 1.4+ doesn't support the -1.1 switch anymore. Ignore this option.

This appears to be a known issue.

RELNOTES=n/a