[Feature] support @Mapping for an Iterable elements and auto sub-mappings feature

[adalgrim]

Hi,

I'd like to propose a new feature to add in MapStruct. I think it would be very useful if I could write something like this (or something similar):

@Mappings({
    @Mapping(target = "address.locationType", source = "address.locationEnum")
})
List<UserDTO> mapToUsers(List<UserEntity> userEntityList);

to prevent from writing definition of a method to map from the UserEntity to UserDTO only because one field (or a few) has a different name. Thanks to that we can still have only one definition of method to map List to List even if Entity and DTO do not match.

[agudian]

I guess the key to this is generally supporting the notation for iterable/array elements and map key/value elements as introduced in the property-path error messages forsource and target in @Mapping... the example above where the mapping method begins with a collection is only a special case of that...
It would be great if we could use the same property path in an "unmappable property"/"unmapped target property" error message as source/target in the annotation, even if it includes lists/maps...

[gunnarmorling]

Tbh. I don't think this feature pulls its weight.

As soon as you need a second collection mapping method (say from Iterable<UserEntity> to Set<UserDto) you'd end up defining that instance-level method you seek to avoid or you'd duplicate all the mappings on the two collection-level methods (or worse, have slightly different mapping definitions for them).

Also by sticking to the convention of defining mappings on the instance-level method it's easier for other developers to find their ways in mapper definitions.

All in all it's a feature I'd prefer us to not support.