Run maven BestPractices #7961

Pankraz76 · 2025-09-01T09:30:27Z

No description provided.

cpovirk · 2025-09-02T14:34:15Z

This clearly means a lot to you, so I can take some parts that are unlikely to require any discussion, though not everything.

…central-publishing-maven-plugin` versioning. Fixes #7961 RELNOTES=n/a PiperOrigin-RevId: 802132912

Pankraz76 · 2025-09-09T07:47:20Z

Thanks for consider.

…lt, except for `maven-gpg-plugin`. This (I hope) accomplished two classes of goals: - By enabling\[*\] `central-publishing-maven-plugin` by default, we enable it even for _snapshot_ deployment. Advantages: - That causes us to begin deploying snapshots through the new Central system. - That lets the plugin automatically disable `maven-deploy-plugin`. (Compare cl/805882118 for Truth.) And _that_ allows us to remove the explicit configuration of https://central.sonatype.com/repository/maven-snapshots, which is the default for `central-publishing-maven-plugin` but which has been required because `maven-deploy-plugin` demands _some_ value. (Compare cl/805842432 for Truth.) - It ensures that non-release builds _also_ see the versions of plugins that we have requested. That addresses this warning, which google/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 plugin still doesn't _run_ unless someone actually runs `mvn deploy`. The only difference in output that the change causes for a typical build is this: ``` [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. (I suspect that much of the configuration that I'm moving is itself restating the defaults. We carried much or all of it over from the old `oss-parent` in changes like cl/492304151. I may try to clean that up later.) 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. Also, in Guava, remove 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.) RELNOTES=n/a PiperOrigin-RevId: 805841232

…lt, except for `maven-gpg-plugin`. This (I hope) accomplished two classes of goals: - By enabling\[*\] `central-publishing-maven-plugin` by default, we enable it even for _snapshot_ deployment. Advantages: - That causes us to begin deploying snapshots through the new Central system. - That lets the plugin automatically disable `maven-deploy-plugin`. (Compare cl/805882118 for Truth.) And _that_ allows us to remove the explicit configuration of https://central.sonatype.com/repository/maven-snapshots, which is the default for `central-publishing-maven-plugin` but which has been required because `maven-deploy-plugin` demands _some_ value. (Compare cl/805842432 for Truth.) - It ensures that non-release builds _also_ see the versions of plugins that we have requested. That addresses this warning, which #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 plugin still doesn't _run_ unless someone actually runs `mvn deploy`. The only difference in output that the change causes for a typical build is this: ``` [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. (I suspect that much of the configuration that I'm moving is itself restating the defaults. We carried much or all of it over from the old `oss-parent` in changes like cl/492304151. I may try to clean that up later.) 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. Also, in Guava, remove 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.) RELNOTES=n/a PiperOrigin-RevId: 805841232

…lt, except for `maven-gpg-plugin`. This (I hope) accomplished two classes of goals: - By enabling\[*\] `central-publishing-maven-plugin` by default, we enable it even for _snapshot_ deployment. Advantages: - That causes us to begin deploying snapshots through the new Central system. - That lets the plugin automatically disable `maven-deploy-plugin`. (Compare cl/805882118 for Truth.) And _that_ allows us to remove the explicit configuration of https://central.sonatype.com/repository/maven-snapshots, which is the default for `central-publishing-maven-plugin` but which has been required because `maven-deploy-plugin` demands _some_ value. (Compare cl/805842432 for Truth.) - It ensures that non-release builds _also_ see the versions of plugins that we have requested. That addresses this warning, which google/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 the change causes for a typical build is this: ``` [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. (I suspect that much of the configuration that I'm moving is itself restating the defaults. We carried much or all of it over from the old `oss-parent` in changes like cl/492304151. I may try to clean that up later. But I saw in Compile-Testing that some of these changes can have an effect: In that project, the changes enabled Javadoc as part of `install`. That led to errors under JDK 8, so I fixed those by making the `--add-exports` configuration conditional.) 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. Also, in Guava, remove 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.) RELNOTES=n/a PiperOrigin-RevId: 805841232

…lt, except for `maven-gpg-plugin`. This (I hope) accomplished two classes of goals: - By enabling\[*\] `central-publishing-maven-plugin` by default, we enable it even for _snapshot_ deployment. Advantages: - That causes us to begin deploying snapshots through the new Central system. - That lets the plugin automatically disable `maven-deploy-plugin`. (Compare cl/805882118 for Truth.) And _that_ allows us to remove the explicit configuration of https://central.sonatype.com/repository/maven-snapshots, which is the default for `central-publishing-maven-plugin` but which has been required because `maven-deploy-plugin` demands _some_ value. (Compare cl/805842432 for Truth.) - It ensures that non-release builds _also_ see the versions of plugins that we have requested. That addresses this warning, which #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 the change causes for a typical build is this: ``` [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. (I suspect that much of the configuration that I'm moving is itself restating the defaults. We carried much or all of it over from the old `oss-parent` in changes like cl/492304151. I may try to clean that up later. But I saw in Compile-Testing that some of these changes can have an effect: In that project, the changes enabled Javadoc as part of `install`. That led to errors under JDK 8, so I fixed those by making the `--add-exports` configuration conditional.) 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. Also, in Guava, remove 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.) RELNOTES=n/a PiperOrigin-RevId: 805841232

…ult (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`](google/auto#1965 (comment)), 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 google/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>`](https://maven.apache.org/guides/mini/guide-using-extensions.html): ``` [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](https://lists.apache.org/thread/k15x84xvj0tv9gngy2426cpm83d85l61). RELNOTES=n/a PiperOrigin-RevId: 805841232

…ult (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`](#1965 (comment)), 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 google/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>`](https://maven.apache.org/guides/mini/guide-using-extensions.html): ``` [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 #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](https://lists.apache.org/thread/k15x84xvj0tv9gngy2426cpm83d85l61). RELNOTES=n/a PiperOrigin-RevId: 805841232

…ult (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`](google/auto#1965 (comment)), 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 #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>`](https://maven.apache.org/guides/mini/guide-using-extensions.html): ``` [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](https://lists.apache.org/thread/k15x84xvj0tv9gngy2426cpm83d85l61). RELNOTES=n/a PiperOrigin-RevId: 805841232

…ult (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`](google/auto#1965 (comment)), 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 google/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>`](https://maven.apache.org/guides/mini/guide-using-extensions.html): ``` [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](https://lists.apache.org/thread/k15x84xvj0tv9gngy2426cpm83d85l61). RELNOTES=n/a PiperOrigin-RevId: 805841232

…ult (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`](#1965 (comment)), 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 google/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>`](https://maven.apache.org/guides/mini/guide-using-extensions.html): ``` [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 #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](https://lists.apache.org/thread/k15x84xvj0tv9gngy2426cpm83d85l61). RELNOTES=n/a PiperOrigin-RevId: 805841232

…ult (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`](google/auto#1965 (comment)), 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 google/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>`](https://maven.apache.org/guides/mini/guide-using-extensions.html): ``` [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](https://lists.apache.org/thread/k15x84xvj0tv9gngy2426cpm83d85l61). RELNOTES=n/a PiperOrigin-RevId: 805841232

…ult (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`](google/auto#1965 (comment)), 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 #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>`](https://maven.apache.org/guides/mini/guide-using-extensions.html): ``` [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](https://lists.apache.org/thread/k15x84xvj0tv9gngy2426cpm83d85l61). RELNOTES=n/a PiperOrigin-RevId: 805841232

…ult (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`](google/auto#1965 (comment)), 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 google/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>`](https://maven.apache.org/guides/mini/guide-using-extensions.html): ``` [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](https://lists.apache.org/thread/k15x84xvj0tv9gngy2426cpm83d85l61). RELNOTES=n/a PiperOrigin-RevId: 807859217

…ult (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`](#1965 (comment)), 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 google/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>`](https://maven.apache.org/guides/mini/guide-using-extensions.html): ``` [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 #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](https://lists.apache.org/thread/k15x84xvj0tv9gngy2426cpm83d85l61). RELNOTES=n/a PiperOrigin-RevId: 807859217

…ult (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`](google/auto#1965 (comment)), 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 google/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>`](https://maven.apache.org/guides/mini/guide-using-extensions.html): ``` [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](https://lists.apache.org/thread/k15x84xvj0tv9gngy2426cpm83d85l61). RELNOTES=n/a PiperOrigin-RevId: 807859217

…ult (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`](google/auto#1965 (comment)), 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 #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>`](https://maven.apache.org/guides/mini/guide-using-extensions.html): ``` [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](https://lists.apache.org/thread/k15x84xvj0tv9gngy2426cpm83d85l61). RELNOTES=n/a PiperOrigin-RevId: 807859217

Pankraz76 mentioned this pull request Sep 1, 2025

Apply maven BestPractices #7959

Closed

Pankraz76 marked this pull request as ready for review September 1, 2025 09:31

Vincent Potucek added 2 commits September 1, 2025 11:31

org.openrewrite.maven.BestPractices

fd774a3

Run maven BestPractices

881bbf0

Pankraz76 force-pushed the fix-OverrideBothEqualsAndHashCodeOnComparable branch from e6aa3fd to 881bbf0 Compare September 1, 2025 09:31

cpovirk self-assigned this Sep 2, 2025

cpovirk added package=general P2 labels Sep 2, 2025

copybara-service bot pushed a commit that referenced this pull request Sep 8, 2025

Sort pom.xml contents in conventional order, and add a TODO about `…

93e6fc7

…central-publishing-maven-plugin` versioning. Fixes #7961 RELNOTES=n/a PiperOrigin-RevId: 802132912

copybara-service bot mentioned this pull request Sep 8, 2025

Sort pom.xml contents in conventional order, and add a TODO about central-publishing-maven-plugin versioning. #7977

Merged

copybara-service bot closed this in 8f4ad7e Sep 8, 2025

copybara-service bot mentioned this pull request Sep 11, 2025

Move configuration out of sonatype-oss-release to enable it by default (except for maven-gpg-plugin), and update related configuration as necessary. google/guava-beta-checker#56

Closed

copybara-service bot mentioned this pull request Sep 11, 2025

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

Merged

copybara-service bot mentioned this pull request Sep 11, 2025

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

Merged

copybara-service bot mentioned this pull request Sep 11, 2025

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

Merged

copybara-service bot mentioned this pull request Sep 11, 2025

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

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

Run maven BestPractices #7961

Run maven BestPractices #7961

Uh oh!

Pankraz76 commented Sep 1, 2025

Uh oh!

cpovirk commented Sep 2, 2025

Uh oh!

Pankraz76 commented Sep 9, 2025

Uh oh!

Uh oh!

Run maven BestPractices #7961

Run maven BestPractices #7961

Uh oh!

Conversation

Pankraz76 commented Sep 1, 2025

Uh oh!

cpovirk commented Sep 2, 2025

Uh oh!

Pankraz76 commented Sep 9, 2025

Uh oh!

Uh oh!