Found while following the skill on a Jmix 3.0.1 project.
Problem: wrong — the rule as written does not hold.
Task
Adding a settings entity alongside existing ones, all of which carry Lombok accessors.
Where
The "Forbidden" section, specifically the bullet "Lombok annotations (@Data, @Getter, @Setter, etc.) on Jmix entities — they interfere with the entity enhancer and break JPA/Jmix metadata".
What happened
Every persistent entity in the project — Customer, Order, Product, the settings entities — is annotated @Getter @Setter, the entity enhancer runs over them, and the full clean test suite is green. Following the bullet literally would have made the one new entity the only hand-written-accessor class in the model, inconsistent with the dozens around it, for a breakage that does not occur. The bullet is written as one undifferentiated ban, so it gives no way to tell that @Data is the actually dangerous one — it generates equals/hashCode/toString over mutable persistent fields, replacing the identity semantics the framework relies on — while plain @Getter/@Setter only generate accessors. No gate would have flagged either choice. Caught in code review.
Suggested fix
Split the bullet: forbid @Data, @EqualsAndHashCode and @ToString on entities with the identity/lazy-loading reason spelled out, and say that plain @Getter/@Setter are acceptable when the project already uses them consistently. Add "match the accessor style already used by the project's entities" to the steps.
Found while following the skill on a Jmix 3.0.1 project.
Problem: wrong — the rule as written does not hold.
Task
Adding a settings entity alongside existing ones, all of which carry Lombok accessors.
Where
The "Forbidden" section, specifically the bullet "Lombok annotations (
@Data,@Getter,@Setter, etc.) on Jmix entities — they interfere with the entity enhancer and break JPA/Jmix metadata".What happened
Every persistent entity in the project —
Customer,Order,Product, the settings entities — is annotated@Getter @Setter, the entity enhancer runs over them, and the fullclean testsuite is green. Following the bullet literally would have made the one new entity the only hand-written-accessor class in the model, inconsistent with the dozens around it, for a breakage that does not occur. The bullet is written as one undifferentiated ban, so it gives no way to tell that@Datais the actually dangerous one — it generatesequals/hashCode/toStringover mutable persistent fields, replacing the identity semantics the framework relies on — while plain@Getter/@Setteronly generate accessors. No gate would have flagged either choice. Caught in code review.Suggested fix
Split the bullet: forbid
@Data,@EqualsAndHashCodeand@ToStringon entities with the identity/lazy-loading reason spelled out, and say that plain@Getter/@Setterare acceptable when the project already uses them consistently. Add "match the accessor style already used by the project's entities" to the steps.