Thanks for the suggestion @pherklotz. We also just received the same request in #2107. Their Option 1 is identical to yours.

I like the proposal here, with one difference instead of using condition, I think that conditionExpression makes more sense.

If you are still interested in providing a PR can you please sync with @Desislav-Petrov?

Looking at this I got an idea that could be something interesting is as well. We can add a new annotation named @Condition which we can then use in condition. That way you can use some utils for it.

e.g.

@Condition("is42")
default boolean is42(int value) {
    return value == 42;
}

@Condition
default boolean isNotEmpty(String value) {
    return value != null && value.length() > 0;
}

@Mapping(target = "baz", condition = "is42")
@Mapping(target = "someString", condition = "isNotEmpty")
For mapFoo(Bar bar);

We can even look for a single @Condition method which has the source type as input and has a boolean as output, or allow specifying on the @Condition whether it applies to all or not.

This might even solve #2084

Hi @filiphr,

I think I like your proposal more because in addition to what you said, this way we will have proper java code versus "java as a string" as in condition.

Thanks,
Des

I don't mind having both options (conditionExpression and condition). I personally am always more for java code vs an expression (java as string).

Yes, I think the @Condition proposal would be an even better solution for #2084 (when it can be applied to all properties of type)

For #2084 it can even work out of the box by defining some method like:

default <T> boolean isPresent(Optional<T> optional) {
    return optional.isPresent();
}

In theory if we add the support for condition we can have some out of the box conditions that we'll be automatically reused, similar to how it is done for the mapping methods

Thanks for the good ideas, I've just started working on a PR and would have an initial impl shortly.

That's great. Looking forward to reviewing it.

Thanks for all your comments. I really like your idea @filiphr. This allows more complex checks with good readability. @Desislav-Petrov can I help you with the implementation?

@pherklotz why not divide and conq on this one - I'm working on introducing the condition = method name bit. Once i'm done with this you can finish off the second part about introducing the @condition ?

Thanks for the work on this @pherklotz and @Desislav-Petrov. Let us know if you need some help.

One a side note something like this might help us with the presence check for #1075. We'll need a containsKey check as a presence check there.

Hi,

PR: #2148

Haven't implemented the @condition bit as I haven't heard if @pherklotz is interested to finish it off. I'm happy to do it as an extension if I don't hear back.

PR feedback would be appreciated.

Thanks,
Des

Hi,

Cool, if this feature could be done. We require this feature for our use case as well and I also like this solution.

Bg,

Hi,

the solution part from @Desislav-Petrov works already for me. How about the part for @condition annotation? Will it still be implemented.

If not, I'd like to have a try. @filiphr Which parts should I change, if I wanna implement this new @condition annotation?

Bg,
Kevin

I'm doing the @condition bit too, was waiting to hear if @pherklotz still wants to do part of the work or not. Since I haven't heard from him for a while I will continue with adding it.

Hi,
is it possible to use multiple parameters for the given condition. I would like to use protobuf oneof and this condition annotation in combination with a Map<String, String> mapping. So that i can create a generic mapper referring to the required fields in the provided map.

BR

This has now been implemented in the same style as the other functionality of MapStruct.

The new @Condition annotation can be used to mark that a method is a condition check method. There are 2 new options in the @Mapping: conditionQualifiedBy and conditionQualifiedByName which are the qualifiers for a condition.

Methods annotated with @Condition can have similar parameters as the lifecycle @AfterMapping and @BeforeMapping injected.

Hello filiphr,
when should we expect the new functionality to be used?
thanks for all the good work :)

@filiphr : Could you please help me , I have been using @condition method as suggested below link
https://mapstruct.org/documentation/dev/reference/html/#conditional-mapping

But am not seeing this method has been used/invoked in the generated impl class. Could you please assist.

@HemalathaGowdar you created #2688, there is no need to ping people and comment the some things in multiple issues. I've replied to you in #2688