#2946 allow update methods with @SubclassMapping

[D3PSI]

this change implements the functionality to generate update methods
(@MappingTarget methods) in conjunction with @SubclassMapping

[filiphr]

Thanks for your work on this @D3PSI. I've left some comments.

In addition to the comments I have some other remarks:

• Please add some more tests, perhaps by copying the existing tests for normal mapping and applying them for update mappings
• How does the check for subclass mapping exhaustion look like? From what I saw we are doing if (source instanceof SourceType && target instanceof TargetType) then the mapping is done. However, this means that people can make mistakes. Therefore, we need to add some errors and other things like that for this. There are also other scenarios where the target type you are updating might not matter.

Having written the second remark we might need to think for a bit better solution for subclass update mappings. Especially in combinations of what you would like to upgrade and from what.

e.g. Consider the following

class Vehicle {}
class Car extends Vehicle {}
class Bike extends Vehicle {}

class VehicleDto {}
class CarDto extends VehicleDto {}
class BikeDto extends VehicleDto {}

When doing update mappings there are various scenarios

@Mapper
public interface CustomMapper {

    void update(@MappingTarget Vehicle target, VehicleDto source);

}

So what you can now do is the following:

• Use CarDto, BikeDto or VehicleDto to update the target
• Use CarDto to update the Car target
• Use CarDto to update the Bike target
  ...

As you can see with updates there are way more possible combinations that can be done.

[filiphr]

Why is this change needed?

[filiphr]

Remove this and use isExistingInstanceMapping instead

[filiphr]

Why is this needed? Why don't we pass everything in the additional parameters?

[filiphr]

Remove this test and write more thorough tests

[s-jepsen]

Any progress on this PR?