fix: trust builders generated in the same round regardless of builderUsagePackages - #298
Closed
igel-devin-ai wants to merge 1 commit into
Closed
igel-devin-ai wants to merge 1 commit into
igel-devin-ai wants to merge 1 commit into
Conversation
…UsagePackages Builders produced by this processor are always used by other generated builders: the generated-in-round check in BuilderScopeResolver.resolve() now runs before the builderUsagePackages filter instead of after it. Previously, a scoped configuration could silently ignore a co-generated builder and fall back to a DTO consumer, making the scope act as a bug: an explicitly generated builder is trusted, like any other self- generated builder. Update the scoping example (sponsor field now exposes a builder-consumer overload) and adjust the resolver and example tests to the new semantics. Co-Authored-By: Andreas Igel <andreas.igel@computacenter.com>
|
Collaborator
Author
|
Closing per maintainer feedback: generated-in-round builders must honor |
Collaborator
|
This is wrong, builder usage package should always filter out even self generated builders |
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
2 participants
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
Fixes the usage-scope semantics of
BuilderScopeResolver: builders generated by this processor in the same compilation round are now trusted and used regardless ofbuilderUsagePackages— the generated-in-round check inresolve()runs before the usage-scope filter instead of after it.An explicitly generated builder is trusted like any other self-generated builder; previously a scoped configuration could silently drop a co-generated builder and fall back to a plain DTO consumer.
Changes
BuilderScopeResolver.resolve(): moved thegeneratedTypeNameslookup ahead of theusagePackagescheck; javadoc reordered accordingly.ScopedOwnerDtoBuilder(generated example):sponsornow exposes the builder-consumer overloadsponsor(Consumer<SponsorDtoBuilder>)—SponsorDto's builder is generated in the same compilation, so it is used despitesponsorliving outside the usage scope.BuilderScopeResolverTest: registered-but-out-of-usage-scope resolution now assertslib.LibHelperBuilder.ScopedOwnerDtoBuilderTest:sponsorbuilder-consumer overload asserted as present.Split out of #296 as requested — that PR keeps only the
@SimpleBuilderForfeature.