[Improvement]: Refactor Optimizing Interface Move to amoro-common
- Dominant language
- Java
- Stars
- 1.2k
- Forks
- 395
- Avg merge
- 4d 10h
- Merged PRs (30d)
- 33
Description
### Search before asking
- [x] I have searched in the [issues](https://github.com/apache/amoro/issues?q=is%3Aissue) and found no similar issues.
### What would you like to be improved?
Refactor Optimizing Interface Move to amoro-common, Prepare abstract interfaces for optimized support of multi-lake formats.
### How should we improve?
- refactor: extract getStructLikeCollections from TaskProperties to AbstractRewriteFilesExecutor
- refactor: move optimizing SPI interfaces from amoro-format-iceberg to amoro-common
- refactor: replace Iceberg DynConstructors with amoro-common DynConstructors in OptimizerExecutor
### Are you willing to submit PR?
- [x] Yes I am willing to submit a PR!
### Subtasks
_No response_
### Code of Conduct
- [x] I agree to follow this project's [Code of Conduct](https://www.apache.org/foundation/policies/conduct)
Contributor guide
Research direction
Start by tracing TaskProperties.getStructLikeCollections, AbstractRewriteFilesExecutor, and OptimizerExecutor, then locate the optimizing SPI interfaces in the repository. Confirm the existing Iceberg DynConstructors usage and the amoro-common equivalents before changing ownership. Done means the interfaces and constructor usage are moved consistently and the optimizer continues to support the targeted multi-lake formats.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- java
- Domain
- backend, data-engineering
- Issue type
- Refactor
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Quiet
- Clarity
- Mostly clear
- Newbie friendliness
- 45/100