Suggest property name in error message when referring to a non-existent property in @Mapping
#122

Comments

The AP raises an error in case a non-existent property is referenced via @Mapping#source() or target(). It would be awesome to display the name of the most similar existing property in the error message:

Now suppose that I made an error in the: @Mapping(source = "propY", target = "propYc") mapping (target should have been propYcd. I missed propZ all together. Wouldn't it be cool if MapStruct generates a file: SourceTargetMapper.template:

This "template" can then be use to adapt the original SourceTargetMapper. Heck, it could even be used to generate a first attempt :). I noticed (in my case) that creating a mapper is a tedious job. Especially when its a big structure. That takes away much of the advantage of MapStruct.

Many time you don't have control over both the source and the target objects (but properties are awfully similar in name).

Now suppose that I made an error in the: @Mapping(source = "propY", target = "propYc") mapping (target should have been propYcd. I missed propZ all together. Wouldn't it be cool if MapStruct generates a file: SourceTargetMapper.template:

This "template" can then be use to adapt the original SourceTargetMapper. Heck, it could even be used to generate a first attempt :). I noticed (in my case) that creating a mapper is a tedious job. Especially when its a big structure. That takes away much of the advantage of MapStruct.

Many time you don't have control over both the source and the target objects (but properties are awfully similar in name).

This comment has been minimized.

Yes, one could think about having a "one-shot" generator which creates a first draft for a mapper interface. One big question is how one would find the corresponding type, i.e. how to know that Source should be mappable into Target.

Generally I'm a bit skeptical how well something like that would work out in the end, because deciding which types/properties need to be mapped to each other should always be a conscious decision of the user; MapStruct then helps with implementing that configured mapping as easily as possibly.

It's definitely a different thing than I'm having in mind with this issue, which just should create more meaningful error messages.

Yes, one could think about having a "one-shot" generator which creates a first draft for a mapper interface. One big question is how one would find the corresponding type, i.e. how to know that Source should be mappable into Target.

Generally I'm a bit skeptical how well something like that would work out in the end, because deciding which types/properties need to be mapped to each other should always be a conscious decision of the user; MapStruct then helps with implementing that configured mapping as easily as possibly.

It's definitely a different thing than I'm having in mind with this issue, which just should create more meaningful error messages.

This comment has been minimized.

I don't believe in a true "one-shot' generator either. But channeling our output in such a fashion that it ends up in extending / improving the annotations in an existing mapper and aiding the user could be a real benefit. Now, obviously we cannot do that in the source code itself, hence the introduction of a .template in the generated-sources.

Don't get me wrong.. I think it is a very good idea to provide meaningful hints. 👍

However, now, they are 'just' messages that we report as warnings and errors. A first step could for instance be introducing - and including the errors and warnings on the spot that they occur in the model (e.g. the mapper to be generated). So in essence, treating them similar as all other model elements we discover in the creation process. Then a message can still be generated as is the case now.

In a later phase a new processor can be introduced, that takes the model again and writes either all errors to system.error or does something special with it (like the idea proposed here).
Anyway, the nice thing about MapStruct is that this can actually be done in a non-intrusive way. In any other run-time / reflection mapper implementation this is more difficult. So this could be a strong selling point :).

I don't believe in a true "one-shot' generator either. But channeling our output in such a fashion that it ends up in extending / improving the annotations in an existing mapper and aiding the user could be a real benefit. Now, obviously we cannot do that in the source code itself, hence the introduction of a .template in the generated-sources.

Don't get me wrong.. I think it is a very good idea to provide meaningful hints. 👍

However, now, they are 'just' messages that we report as warnings and errors. A first step could for instance be introducing - and including the errors and warnings on the spot that they occur in the model (e.g. the mapper to be generated). So in essence, treating them similar as all other model elements we discover in the creation process. Then a message can still be generated as is the case now.

In a later phase a new processor can be introduced, that takes the model again and writes either all errors to system.error or does something special with it (like the idea proposed here).
Anyway, the nice thing about MapStruct is that this can actually be done in a non-intrusive way. In any other run-time / reflection mapper implementation this is more difficult. So this could be a strong selling point :).