Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Fix double-source-jar error during releases:
``` Building and deploying the android flavor (this may take a while)... [ERROR] We have duplicated artifacts attached. [ERROR] Failed to execute goal org.apache.maven.plugins:maven-source-plugin:3.3.0:jar (attach-sources) on project guava: Presumably you have configured maven-source-plugn to execute twice times in your build. You have to configure a classifier for at least on of them. -> [Help 1] ``` I had fixed the same issue with _snapshot_ deployment in cl/559489724 (by no longer passing `source:jar` to `mvn`), but apparently that fix doesn't apply to _release_ deployment. I'm guessing that the relevant part of our release command is `-Psonatype-oss-release`, which (among other things) [activates a `maven-source-plugin` configuration change](https://github.com/google/guava/blob/a78bea41aedba50469641968ee3d98b24836e491/pom.xml#L329-L334): Presumably that introduces a second `maven-source-plugn` execution in much the same way as passing `source:jar` does. I previously fixed a similar problem in jimfs (cl/536746714) by removing the "normal" `maven-source-plugin` configuration, leaving only the `sonatype-oss-release` configuration in the parent. (I don't remember whether I investigated removing the `sonatype-oss-release` configuration instead. Probably I should have at least investigated.) So I'm doing the same for Guava in this CL. Hopefully this won't interfere with _snapshot_ source jars, which currently are produced even without `source:jar` but might no longer be. If it does cause problems, then I should _definitely_ investigate removing the `sonatype-oss-release` configuration instead. (Encouragingly, [jimfs snapshots](https://oss.sonatype.org/content/repositories/snapshots/com/google/jimfs/jimfs/HEAD-SNAPSHOT/) appear to be fine... _but_ jimfs [still passes `source:jar`](https://github.com/google/jimfs/blob/acb81e8718adf2527be105c6c9b130ec788c9877/.github/workflows/ci.yml#L81).... So I do somewhat expect this to blow up—but, on the bright side, to also teach me something, at which point maybe we can get the config right for both these projects and others to come.) (I went to check whether `guava-*-source.jar` was still being generated in my test release. But somehow I see _no_ jars under `guava/target`, even as I see all(?) the expected ones under `guava-testlib`, etc. I wonder if the release script did a little housekeeping? Sigh, this is really going to blow up, isn't it?) (Notice that the configuration that may be the source of the problem was copied from the old `oss-parent` pom. This is at least the second time that that pom's configuration has caused us trouble, the other I recall being cl/492304151—well, and probably the aforementioned jimfs source-jar issue, too.) This prepares for the release that contains the fix for #6634, among other issues. RELNOTES=n/a PiperOrigin-RevId: 571437790
- Loading branch information