Skip to content

Conversation

@DanielLiu1123
Copy link
Contributor

  • Add JavaFileMerger class for standalone Java file merging using JavaParser
  • Modify DefaultShellCallback to support Java file merging by default
  • Support merging based on @mbg.generated JavaDoc tags and @Generated annotations (javax/jakarta)
  • Preserve custom methods while updating generated methods
  • Update JavaParser dependency scope to make it available for main code

This enables automatic merging of Java Mapper files during regeneration, similar to the existing XML merge functionality.

Close #595

DanielLiu1123 and others added 7 commits September 14, 2025 14:31
- Add JavaFileMergerJavaParser class for standalone Java file merging using JavaParser
- Modify DefaultShellCallback to support Java file merging by default
- Support merging based on @mbg.generated JavaDoc tags and @generated annotations (javax/jakarta)
- Preserve custom methods while updating generated methods
- Add comprehensive tests and demo for the merge functionality
- Update JavaParser dependency scope to make it available for main code

This enables automatic merging of Java Mapper files during regeneration,
similar to the existing XML merge functionality.
…ctices

- Rewrite mergeImports method to sort imports according to Java best practices:
  1. java.* packages (alphabetically)
  2. javax.* packages (alphabetically)
  3. jakarta.* packages (alphabetically)
  4. Third-party and project packages (alphabetically)
  5. Static imports (alphabetically, at the end)
- Add ImportInfo helper class to handle import deduplication and comparison
- Implement compareImports method with proper priority-based sorting
- Update existing test expectations to match new sorted import order
- Add comprehensive test shouldSortImportsAccordingToBestPractices to verify:
  * Correct ordering of different package types
  * Proper handling of static imports
  * Alphabetical sorting within each category
- All 10 tests pass successfully
- Import output is now predictable and follows industry standards
@coveralls
Copy link

coveralls commented Jan 28, 2026

Coverage Status

coverage: 89.789% (-0.2%) from 89.986%
when pulling 48406e7 on DanielLiu1123:feat-merge-mapper
into fe115ed on mybatis:master.

@jeffgbutler
Copy link
Member

@DanielLiu1123 thanks for the contribution!

I'm going to work on this a bit more before I merge it.

@jeffgbutler jeffgbutler added this to the 2.0.0 milestone Jan 28, 2026
@jeffgbutler jeffgbutler merged commit 8ce80c6 into mybatis:master Jan 28, 2026
20 of 21 checks passed
@jeffgbutler
Copy link
Member

We're going to call this an experimental feature for now, and it must be explicitely requested by a user. I will also add more tests from the Eclipse plugin. But this is an awesome start - thanks @DanielLiu1123!

@DanielLiu1123
Copy link
Contributor Author

@jeffgbutler I just realized the code after the merge might not have been formatted. Could you please double-check?

@hazendaz
Copy link
Member

hazendaz commented Jan 29, 2026 via email

@DanielLiu1123
Copy link
Contributor Author

Sorry for the confusion. What I meant was that the code generated by the generator did not go through JavaFormatter, which can cause formatting differences when the code is regenerated compared to previous versions. I was not referring to the code submitted in this PR being unformatted.

@jeffgbutler
Copy link
Member

@DanielLiu1123 thanks for bringing this up. I'll be bringing in my big test framework so we can exercise this new feature more fully - so we can address this later. I do think we'll need to add some method of configuring the formatter

@jeffgbutler
Copy link
Member

BTW - I looked in the code. You call toString() on the result, which invokes the default printer in JavaParser. So it is formatted according to their default style.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

java file merge

4 participants