unmapped target property boolean with is prefix

[drej1]

Hi,

I have the following mapper:

@Mapping(target = "isAdded", constant = "true")
@Mapping(target = "categories", source = "productCategories")
AddedService mapManageableAssetToAddedService(ManageableAsset manageableAsset);

while the target model AddedService (it is generated from swagger) has a the following field and getter/setter:

@JsonProperty("isAdded")
private Boolean isAdded = null;

public AddedService isAdded(Boolean isAdded) {
    this.isAdded = isAdded;
    return this;
}

/**
 * if true, used to mark services added to profile
 * @return isAdded
**/
@ApiModelProperty(value = "if true, used to mark services added to profile")
public Boolean getIsAdded() {
    return isAdded;
}

public void setIsAdded(Boolean isAdded) {
    this.isAdded = isAdded;
}

In this situation the idea plugin says Unmapped target property: added
(The situation is the same if the source model contains same field and same methods.)

It looks that the "fluent" method public AddedService isAdded(Boolean isAdded) causes the problem.

Can You fix this?

Thanks

[xco-sk]

+1 same issue in Idea plugin v1.1.0

[filiphr]

@drej1 just to make it clearer. The Unmapped target property comes only from the plugin? When you run a normal compilation via your own build tool is the warning there?

[drej1]

Hi @filiphr, yes we have unmappedTargetPolicy = ReportingPolicy.ERROR and it compiles. For example, if I remove the annotation @Mapping(target = "isAdded", constant = "true") the build fails with compilation error.
So it is problem only of the plugin

[drej1]

Hi @filiphr, did you have time to take a look on this?
Thanks :)

[filiphr]

@drej1 sorry for the late reply no I haven't had time to look into this. However, I think I know what the problem is. Will need to write a test to be able to fix it.

Might take some time. You are also welcome to help with a PR if you want to :)

[filiphr]

This is now fixed on master. Apart from the warning the property was also reported twice. This is now fixed and follows the same principle as the DefaultAccessorNamingStrategy

[drej1]

@filiphr thanks!
Sorry I didn't have time to check the plugin implementation and couldn't help with the fix.

When 1.2.0 will be out, we will test this.
Thanks!