Skip to content

Conversation

@eiswind
Copy link
Contributor

@eiswind eiswind commented May 7, 2017

Null values don't work, as this is not supported in the Builder.

@filiphr
Copy link
Member

filiphr commented May 7, 2017

You can use @Mapper(nullValueCheckStrategy = NullValueCheckStrategy.ALWAYS). With this the source properrties are always checked and assigned if they are not null.

@eiswind
Copy link
Contributor Author

eiswind commented May 8, 2017

Thx. I added the NullValueCheckStrategy. Null values now map to the protobuf defaults. I added the testcase to illustrate the behaviour.

Copy link
Contributor

@sjaakd sjaakd left a comment

Choose a reason for hiding this comment

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

@eiswind .. Nice demonstrator. Thanks! I've some small improvements and a question. Let me know what you think.

String methodName = super.getPropertyName(adderMethod);
Element receiver = adderMethod.getEnclosingElement();
if (receiver != null) {
TypeElement type = (TypeElement) ((DeclaredType) receiver).asElement();
Copy link
Contributor

Choose a reason for hiding this comment

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

I would rewrite the routine a little bit. Don't think its required go from a element to a DeclaredType to a TypeElement if you already know its a class. So like this:

    @Override
    public String getElementName(ExecutableElement adderMethod) {

        String methodName = getPropertyName( adderMethod );
        Element receiver = adderMethod.getEnclosingElement();
        if ( receiver != null && receiver.getKind() == ElementKind.CLASS ) {
            TypeElement type = (TypeElement) receiver;
            TypeMirror superType = type.getSuperclass();
            if ( superType != null && PROTOBUF_MESSAGE_V3.equals( superType.toString() ) ) {
                methodName += LIST_SUFFIX;
            }

        }
        return methodName;
    }

(I also would recommend using constants).

Copy link
Contributor Author

Choose a reason for hiding this comment

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

That looks nicer. I was glad to make it work, have never used this part of api before.

<plugin>
<groupId>org.xolstice.maven.plugins</groupId>
<artifactId>protobuf-maven-plugin</artifactId>
<version>0.5.0</version>
Copy link
Contributor

Choose a reason for hiding this comment

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

can you add plugin versions to properties defined at protbuf parent level? That makes them easy to maintain.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

yap

<build>
<extensions>
<extension>
<groupId>kr.motd.maven</groupId>
Copy link
Contributor

Choose a reason for hiding this comment

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

Is this extension needed for protobuf?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

It allows platform detection so that maven can pull the correct binaries for protoc
${os.detected.classifier}

user.setEmail("test");
user.getPermissions().add(Permission.ADMIN);

UserDTO.Builder dto = UserMapper.INSTANCE.map(user);
Copy link
Contributor

Choose a reason for hiding this comment

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

ah.. the good old round-trip.. 😄 I was thinking.. Would it be good to call the serializing functions in protobuf and deserialize in a fresh object? Just to show its working end-to-end..

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Never have done that before :) But it's good to see that it works.

@sjaakd
Copy link
Contributor

sjaakd commented May 8, 2017

See also #14

@eiswind
Copy link
Contributor Author

eiswind commented May 9, 2017

I just pushed the changes. Thx for the feedback.

@Override
public String getElementName(ExecutableElement adderMethod) {

String methodName = getPropertyName(adderMethod);
Copy link
Member

Choose a reason for hiding this comment

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

I didn't notice this before., but you are calling getPropertyName(adderMethod) instead of super.getElementName(adderMethod). It currently works, because in getPropertyName() we always strip the first 3 characters. However, I think that it is more correct if you just call super.getElementName(adderMethod)

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Absolutely.

*/
public class ProtobufAccessorNamingStrategy extends DefaultAccessorNamingStrategy {

public static final String PROTOBUF_GENERATED_MESSAGE_V3 = "com.google.protobuf.GeneratedMessageV3";
Copy link
Member

Choose a reason for hiding this comment

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

Again something I read on the protbuf website (I have no real experience). It says that GeneratedMessage is an implementation detail and that the builders are implementing Message.Builder or MessageLite.Builder depending on something you pick in the .proto

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I have no clue how to check that with that part of the java api, sorry.

@filiphr
Copy link
Member

filiphr commented May 11, 2017

@eiswind Thanks a lot for the example. I think that it is a really nice addition.

Regarding my #25 (comment). If you think that it is worth it and it is OK for you, I can add that to your PR, or create a new one, that will do that.

Additionally you had some questions in one of the issues, about not needing to use permissionsList. Do you think that it would be better if you didn't need to write @Mapping(source = "permissions", target = "permissionsList")?

Finally, will it be OK for you if I squash all the commits into one before merging, or you would prefer to have them as is merged into the examples?

@eiswind
Copy link
Contributor Author

eiswind commented May 15, 2017

Feel free to make your changes as you prefer!

@filiphr filiphr merged commit db0be77 into mapstruct:master Jul 16, 2017
@filiphr
Copy link
Member

filiphr commented Jul 16, 2017

Thanks for the PR @eiswind, sorry for taking so long to merge it.

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.

3 participants