feat: add S3 delete utilities and support for Content-MD5 header in delete requests#727
feat: add S3 delete utilities and support for Content-MD5 header in delete requests#727funky-eyes wants to merge 12 commits intoAiven-Open:mainfrom
Conversation
storage/s3/src/main/java/io/aiven/kafka/tieredstorage/storage/s3/S3Storage.java
Outdated
Show resolved
Hide resolved
storage/s3/src/main/java/io/aiven/kafka/tieredstorage/storage/s3/S3Storage.java
Outdated
Show resolved
Hide resolved
…s3/S3Storage.java
…s3/S3Storage.java
|
@jeqo Could you tell me which code formatter, configuration, and commands I should use so my code meets the project's formatting requirements? |
|
Hi, @funky-eyes, thanks for the PR. There is checkstyle config in ./checkstyle directory and a corresponding Gradle tasks to validate the code against the defined rules. There is no automatic formatter. |
…e-kafka into 0826
Hi @AnatolyPopov, the CI checks have passed. Could you please review the code? Thanks! |
|
Since there is already a plugin in AWS SDK for this, as I mentioned in another comment, closing this one in favor of #728 |
I believe the community should remain truly open source. We should guide contributors to improve their PRs so they better fit the project's standards, rather than handling an issue ourselves and then, when others submit fixes, deeming those fixes “unsuitable,” implementing our own solution and closing their PRs. That feels disrespectful to contributors. Isn’t code review supposed to be how community members, committers, and the PMC help PRs meet the project’s norms, standards, and functional requirements? If a PR is unsatisfactory, closing it without offering guidance is neither open nor respectful of other people’s work. I’ve encountered this twice in this community: once when I added S3 upload rate limiting using Bucket4j, and now again. |
|
Hi @funky-eyes, I’m sorry if closing your PR felt dismissive — that wasn’t my intention. In the issue comment I was trying to highlight that the newer version of AWS SDK already included a fix. To avoid suggesting something that might cause other issues, I tested the approach myself and confirmed a working solution. I then submitted a PR so the fix could be available right away, rather than asking you to spend more time reiterating on it. I realize I should have explained this more clearly, and I truly value the time and effort you put into your contribution. |
About this change - What it does
Resolves: #694
Why this way