refactor: extract provider-specific config into ProviderProfile (Strategy)#78
Merged
Merged
Conversation
S3Configuration was starting to accumulate provider-specific optional fields (account-id for R2, alongside checksum-validation and the generic fields) that only ever matter for one particular backend. Adding the next provider's shorthand would mean growing the shared interface again. Introduces a small ProviderProfile abstraction instead: each profile knows how to recognize its own shorthand config and resolve it into the plain endpoint-url/force-path-style/region settings S3FileSystemFactory already understood. The factory itself no longer has any R2-specific logic - it just asks ProviderProfiles.resolve() for the effective connection settings. - ProviderProfile: the resolve contract + ResolvedEndpoint record - R2Profile: derives the R2 endpoint from account-id, forces path-style - GenericS3Profile: passes cfg's own endpoint-url/force-path-style/ region through unchanged - the fallback, tried last - ProviderProfiles: tries each profile in order, first match wins No config/behavior change for existing users. Adding a future provider's own shorthand (e.g. a hypothetical B2 profile) now means adding one small profile class, not touching the shared config interface or the factory.
2 tasks
TheMeinerLP
added a commit
that referenced
this pull request
Jul 13, 2026
Resolves the squash-merge ancestry gap left by #77's squash-merge: this branch had #78's ProviderProfile refactor on top of the pre-squash commit, so a normal merge against main's post-squash tip showed spurious conflicts on lines that were actually already superseded (main's version) by this branch's version (confirmed identical file-by-file diff before this merge).
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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
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.
Summary
Stacked on #77.
S3Configurationwas starting to accumulate provider-specific optional fields (account-idfor R2, alongside the generic ones) that only ever matter for one particular backend — adding the next provider's shorthand would mean growing the shared interface again.Introduces a proper Strategy pattern instead of the inline
if (usingAccountId)branch #77 had inS3FileSystemFactory:ProviderProfile: the strategy contract (resolve()) plus a stableid()for explicit selection.R2Profile/GenericS3Profile: one strategy per provider convention.R2Profilederives the endpoint fromaccount-id;GenericS3Profilepassesendpoint-url/force-path-style/regionthrough unchanged and is the fallback.ProviderProfiles: selects the strategy. New optionalproviderconfig field picks one explicitly by name (r2/generic) if set; otherwise falls back to auto-detecting from which fields are populated (e.g.account-idset →r2), so existing zero-config setups keep working unchanged.S3FileSystemFactoryitself no longer has any R2-specific logic, it just asksProviderProfiles.resolve()for the effective connection settings. Adding a future provider's own shorthand means adding one small profile class + registering it, not touching the shared config interface or the factory.No config/behavior change for existing users;
provideris opt-in for when you want to be explicit instead of relying on auto-detection.Test plan
./gradlew compileJavapasses./gradlew spotlessApply— no formatting changes beyond this refactor