Possibly related to #1547
I've recently been playing with 1.3 (from 1.2), testing out builder/immutable object support. I'm trying to map between 2 classes, a service layer DTO and our internal model representation. Currently, our internal model is a lombok @Data class, as mapstruct requires mutable objects. Ideally, we'd move to @Value or otherwise make an immutable object, as part of the 1.3 upgrade.
The DTO is generated, mutable and comes with a builder class, the builder has setters named withAttribute. Mapstruct 1.3 doesn't know how to map these out of the box -- it tries to use the builder then complains about not mapping withAttribute. I started trying out the AccessorNamingStrategy spi. It works, but I have to support all strategies with a single class (mapstruct throws if you provide more than 1 implementation).
Aside: I found this to be odd, as ServiceLoaders typically get multiple implementations of a service (like Processor). This would allow me to write a single class to support a withAttribute naming strategy, without having to worry about supporting setAttribute or attribute still. Mapstruct could in theory support multiple by trying all implementations before being unable to find a method.
While, strictly speaking, this universal naming strategy worked, I didn't feel confident that the strategy would cover all existing cases across all of our code, and future cases may be hard to integrate and be blocked.
So. Not overly confident in that, I searched for some way to simply turn off builder support. It seems this is only possible mapstruct-wide.
In case you want to disable using builders then you can use the NoOpBuilderProvider by creating a org.mapstruct.ap.spi.BuilderProvider file in the META-INF/services directory with org.mapstruct.ap.spi.NoOpBuilderProvider as it’s content.
Not ideal, as I wanted to change our internal model to be immutable and don't want to support withAttribute through the spi. For my situation, I'd rather see a way to specify this method, use the builder; this method, it's just a bean. Specifying an arg as "don't use builders" would be a seamless way for me to upgrade, but mapstruct's default could be "autodetect builders" as it currently does. Overriding this config at a mapper or method level would allow me to opt-in to new features, so the new version is fully backward compatible.
Possibly related to #1547
I've recently been playing with 1.3 (from 1.2), testing out builder/immutable object support. I'm trying to map between 2 classes, a service layer DTO and our internal model representation. Currently, our internal model is a lombok
@Dataclass, as mapstruct requires mutable objects. Ideally, we'd move to@Valueor otherwise make an immutable object, as part of the 1.3 upgrade.The DTO is generated, mutable and comes with a builder class, the builder has setters named
withAttribute. Mapstruct 1.3 doesn't know how to map these out of the box -- it tries to use the builder then complains about not mappingwithAttribute. I started trying out theAccessorNamingStrategyspi. It works, but I have to support all strategies with a single class (mapstruct throws if you provide more than 1 implementation).Aside: I found this to be odd, as
ServiceLoaders typically get multiple implementations of a service (likeProcessor). This would allow me to write a single class to support awithAttributenaming strategy, without having to worry about supportingsetAttributeorattributestill. Mapstruct could in theory support multiple by trying all implementations before being unable to find a method.While, strictly speaking, this universal naming strategy worked, I didn't feel confident that the strategy would cover all existing cases across all of our code, and future cases may be hard to integrate and be blocked.
So. Not overly confident in that, I searched for some way to simply turn off builder support. It seems this is only possible mapstruct-wide.
Not ideal, as I wanted to change our internal model to be immutable and don't want to support
withAttributethrough the spi. For my situation, I'd rather see a way to specify this method, use the builder; this method, it's just a bean. Specifying an arg as "don't use builders" would be a seamless way for me to upgrade, but mapstruct's default could be "autodetect builders" as it currently does. Overriding this config at a mapper or method level would allow me to opt-in to new features, so the new version is fully backward compatible.