Annotating @Mapping with "not handled here"?

[Stefan Hoffmeister]

Hello everybody,

I recently discovered MapStruct (1.3.1, now 1.4.0) and have applied this, over the course of the past few days, with good success in an initial project - so thank you for MapStruct!

In the course of some experimentation, I have run into a scenario where MapStruct emits a warning along the lines of

        Unmapped target property: "computedComplexElement". Mapping from property "ObjectA a" to "ObjectB b"

Well, yes, true. I am using a decorator with @DecoratedWith to get full control over the content of computedComplexElement in my mapping (this is actually complex internationalized string rendering of a number of source elements).

Now, my current (design / architecture) perspective on MapStruct is that it acts as an embedded DSL, quite obviously emitting compile-time diagnostics (see above) for any discrepancy the built-in "compiler" / "assembler" (code generator) detects. Therefore I feel quite obliged to satisfy not only the "it compiles" constraint, but also the "it does not emit diagnostics" requirement. And here we go: I can easily

     @Mapping(target = "computedComplexElement", ignore = true)

to suppress the warning. But I don't want to suppress the warning - I want to indicate that, in fact, I am not ignoring this target, but am handling that complex mess "elsewhere". Because of that, "ignore" very much sends the wrong message - I don't ignore the target (one could argue that "ignore" translates to "ignore here" - but that's too indirect for the casual reader of code).

For now, I have resorted to

     @Mapping(target = "computedComplexElement", ignore = true) // decorator

but given my loathing of comments (or on-the-side documentation), I am not happy with that approach. Alas, I don't see a better approach at the moment.

So I am looking for suggestions on how to better bake into the source code, at compile-time, the fact that, yes, I am mapping that, just not here.

I understand that inventing a new MapStruct attribute "decorated = true" would satisfy my expressive needs, but could not ever be added into the MapStruct framework itself, as MapStruct would never be able to guarantee that implied contract.

Perhaps I am missing some aspect of MapStruct, where I can declare dependencies such that target = "computedComplexElement" and source = {"c.alpha", "d.beta", "e.gamma"} optionally with a dedicated qualifiedBy converter (with type-checked parameters given the sources) to provide mapping. This would add a lot of declarative expressiveness. Anyone?

And with that, I am out of ideas...