fix: correct Maven POM configuration for Lombok and MapStruct compatibility #7
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
…bility
Fix critical configuration issues in pom.xml that could cause compilation failures when using Lombok and MapStruct together.
## Changes
### Dependencies
- Add explicit `<packaging>jar</packaging>` declaration
- Add `lombok.version` property for consistency (1.18.30)
- Add `lombok-mapstruct-binding` dependency (0.2.0) - **Critical for Lombok+MapStruct compatibility**
- Add `spring-security-test` dependency for security testing support
### Compiler Configuration
- Replace `<source>` and `<target>` with `<release>${java.version}` (modern Java 9+ approach)
- Add `lombok-mapstruct-binding` to annotation processor path with correct order:
1. Lombok (generates code)
2. Lombok-MapStruct binding (bridges both libraries)
3. MapStruct processor (uses Lombok-generated code)
## Why These Changes Matter
**lombok-mapstruct-binding**: Without this binding, MapStruct cannot properly process Lombok-annotated classes, leading to compilation errors when generating mappers for entities with @DaTa, @builder, etc.
**Annotation processor order**: The order matters - Lombok must run first to generate getters/setters, then the binding bridges them, and finally MapStruct can use the generated code.
**Release vs Source/Target**: Using `<release>` is the recommended approach since Java 9, providing better cross-compilation guarantees.
## References
- Maven POM Best Practices: https://maven.apache.org/guides/introduction/introduction-to-the-pom.html
- Lombok-MapStruct Integration: https://mapstruct.org/faq/#can-i-use-mapstruct-together-with-project-lombok
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude <noreply@anthropic.com>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Summary
Fix critical Maven POM configuration issues that could cause compilation failures when using Lombok and MapStruct together. These changes ensure proper annotation processing order and add missing dependencies for compatibility.
Changes Made
🔧 Dependencies
<packaging>jar</packaging>declaration for claritylombok.versionproperty (1.18.30) for version consistencylombok-mapstruct-bindingdependency (0.2.0) - Critical for Lombok+MapStruct compatibilityspring-security-testdependency for security testing support⚙️ Compiler Configuration
<source>21</source>and<target>21</target>with modern<release>${java.version}</release>lombok-mapstruct-bindingto annotation processor path with correct order:Why These Changes Matter
🚨 Critical Fix: lombok-mapstruct-binding
Without this binding, MapStruct cannot properly process Lombok-annotated classes. This causes compilation errors when generating mappers for entities using
@Data,@Builder,@Getter, etc.📋 Annotation Processor Order
The processing order is crucial:
🎯 Modern Java Compilation
Using
<release>instead of<source>/<target>is the recommended approach since Java 9, providing better cross-compilation guarantees and ensuring bytecode compatibility.Testing Checklist
mvn clean compileReferences
🤖 Generated with Claude Code