Fix some problems with the Central Publishing Portal setup after cl/786033817: #7891
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
![copybara-service[bot]](https://avatars.githubusercontent.com/in/44061?s=60&v=4){kind=small}
copybara-service
bot
force-pushed
the
test_786078646
branch
from
b6d02ff to
b9d741d
Compare
…86033817: - Stop inheriting from `oss-parent` in `guava-bom`. I'm seeing `guava-bom` try to deploy to the old `oss.sonsatype.org`, even as the other subprojects successful deploy to `central.sonatype.com`, and I believe that's a result of the parent. I put in the new Central config to compensate. (I don't remember if we have a good reason for `guava-bom` to not inherit from `guava-parent`, but I figure there's some chance we do. I could look into it.) - Skip `central-publishing-maven-plugin` for `guava-tests`, just as we did for `maven-deploy-plugin`. I haven't seen evidence that this is a problem yet, but that may be only because: - We've attempted only snapshot releases, not "full" releases? I think that some problems "like this" have appeared only during validation of full releases, at least historically. - The snapshot release failed before it even got to `guava-tests`. - Avoid mentioning `maven-deploy-plugin` in `guava-tests` and even in our `pluginManagement`. We should no longer be using it, so we shouldn't need to specify a version. - Remove entry for `sonatype-nexus-staging`. That entry may or may not actually be a "problem," but I'd meant to remove it in the previous CL for all our projects. I just missed Guava (because I started with a list of projects that _depend_ on Guava and then went back for Guava). (Here's [the log for the failure](https://github.com/google/guava/actions/runs/16457531993/job/46518814913).) RELNOTES=n/a PiperOrigin-RevId: 786274873
copybara-service
bot
force-pushed
the
test_786078646
branch
from
b9d741d to
87976cd
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Fix some problems with the Central Publishing Portal setup after cl/786033817:
oss-parentinguava-bom. I'm seeingguava-bomtry to deploy to the oldoss.sonsatype.org, even as the other subprojects successful deploy tocentral.sonatype.com, and I believe that's a result of the parent. I put in the new Central config to compensate. (I don't remember if we have a good reason forguava-bomto not inherit fromguava-parent, but I figure there's some chance we do. I could look into it.)central-publishing-maven-pluginforguava-tests, just as we did formaven-deploy-plugin. I haven't seen evidence that this is a problem yet, but that may be only because:guava-tests.maven-deploy-plugininguava-testsand even in ourpluginManagement. We should no longer be using it, so we shouldn't need to specify a version.sonatype-nexus-staging. That entry may or may not actually be a "problem," but I'd meant to remove it in the previous CL for all our projects. I just missed Guava (because I started with a list of projects that depend on Guava and then went back for Guava).(Here's the log for the failure.)
RELNOTES=n/a