Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

#1742 refactoring and making builder optional #1811

Merged
merged 9 commits into from
May 24, 2019
Merged

Conversation

sjaakd
Copy link
Contributor

@sjaakd sjaakd commented May 8, 2019

Currently the accessor type is defined in PropertyMapper while it should be an intrinsic property of Accessor. Types are fetched and derived in context (again) all-over-the-place.. Sometimes that requires the parent type again and even the mapping method (to derive in context and resolve generics).

Next, builderType is part of type. One could say there is a relation from builderType to Type but not the other way around. A builderType could be in a completely different package. It's still not as I want.. But I managed to move the builderType (mostly) to the place were its relevant: the BeanMappingMethod.

Done!

I'm still not completely happy with the number of places were I do need to consult the typeFactory for the effectiveType or the builderType. This indicates a bad separation of concerns. Probably stemming from the fact that we do analyse a nested target and try to find the associated types in TargetReference. I think that in the end TargetReference and SourceReference should be handled in the BeanMappingMethod and not in Mapping upfront but in the context of the BeanMappingMethod.

I experimented with making annotations and annotation fields Optional. I think we should apply this pattern, because we keep on doing null checks all over the place.

Fixes #1742

@sjaakd sjaakd changed the title 1742 #1742 refactoring and making builder optional May 8, 2019
@sjaakd sjaakd requested review from filiphr and chris922 May 8, 2019 21:58
Copy link
Member

@filiphr filiphr left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Wow @sjaakd this is an amazing PR 😄.

All your points are on point.

Regarding the SourceReference and TargetReference they are already used mostly within a BeanMappingMethod context. They are derived from the @Mapping that is mostly used for bean mapping methods. Or am I missing something? In any case you are completely right about the separation of the concerns.

I experimented with making annotations and annotation fields Optional. I think we should apply this pattern, because we keep on doing null checks all over the place.

IMP doing a not null check vs Optional#isPresent there is not a big difference.

I've added some comments to the PR. My "biggest" concern is the naming of the noBuilder. For some reason it doesn't stick with me. How about disableBuilder? Maybe something else, I am open to suggestions.

@filiphr
Copy link
Member

filiphr commented May 24, 2019

I forgot to mention. This PR would also solve #1661, right?

@sjaakd
Copy link
Contributor Author

sjaakd commented May 24, 2019

I forgot to mention. This PR would also solve #1661, right?

it does..

@filiphr
Copy link
Member

filiphr commented May 24, 2019

For #1661 let's also add an annotation processor option. So this would partially solve it.

@filiphr
Copy link
Member

filiphr commented May 24, 2019

Thanks for the updates. LGTM for merging

@sjaakd sjaakd merged commit 3371058 into mapstruct:master May 24, 2019
@sjaakd sjaakd deleted the 1742 branch May 24, 2019 21:30
@chris922
Copy link
Member

I just had a quick glance at your changes, looks awesome. Thanks @sjaakd !

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

MapStruct 1.3.0.Final produces uncompilable code when using Java 11 + Lombok 1.18.6
3 participants