Compatibility with non-JavaBeans-style property accessors

[danielsonjh]

The following docs from AutoValue and Immutables seem to indicate that both libraries do not recommend using the JavaBeans-style property accessors (getProperty(), isBoolean(), etc)
https://github.com/google/auto/blob/master/value/userguide/index.md
https://immutables.github.io/

Both libraries do support JavaBeans-style accessors to some degree however
https://github.com/google/auto/blob/master/value/userguide/howto.md#beans
https://immutables.github.io/style.html

In Mapstruct 1.3.0.Beta1 only JavaBeans-style properties are supported.
To support this new convention, Mapstruct will need an option to treat all methods as potential properties.
With no differentiation between standard methods and property getters, it seems that Mapstruct either needs:

1. Mapped classes to only have property getters as methods.
2. An annotation to allow Mapstruct to ignore certain methods when not using JavaBeans-style conventions.

Option 1 is up to the developer, and for Option 2, there is already an annotation that can do this, @Mapping(target = "somemethod", ignore = true)

[filiphr]

@danielsonjh I think that someone else requested this as well, but I am not sure if it was within an issue.

As you noticed Option 2 is already in there. As for Option 1 it can be achieved by using a custom AccessorNamingStrategy and it is not that difficult to write for your own use. I don't see why such an opt in strategy won't be acceptable for us (if someone wants to contribute it). The only thing is that one needs to be really careful as then all methods would be considered as properties.

[sjaakd]

and Immutables already works out-of-the box with fluent-accessors, right? #1608 reports something similar for Lombok..

[filiphr]

Everything works out-of-the box with fluent setters. There are no fluent getters actually. As fluent implies that you get the same object back and for getters you get something else.

[debug-desperado]

With immutables I think it makes the most sense to consider all methods as properties, and then have the user exclude derived, lazy, and check methods if they cause problems (@Value.Derived, @Value.Lazy, @Value.Check). Those won't be on the builders, but I'm not sure how MapStruct could use that information.

Looking briefly over the code, if ImmutablesAccessorNamingStrategy extended CustomAccessorNamingStrategy instead of DefaultAccessorNamingStrategy, wouldn't that have this effect?

[filiphr]

@debug-desperado CustomAccessorNamingStrategy is within the tests. In any case even if that is done it won't have the effect that you explained.

As I said in #1601 (comment). This one is marked as up for grabs, so if someone from the community is willing to give it a go we are more than happy to help out