[#1881] fix(client-spark): Make spark client uniifle class under org.apache.uniffle package to avoid conflict#1882
Conversation
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## master #1882 +/- ##
============================================
- Coverage 53.35% 53.16% -0.20%
- Complexity 2846 2991 +145
============================================
Files 428 447 +19
Lines 22805 24435 +1630
Branches 2142 2273 +131
============================================
+ Hits 12167 12990 +823
- Misses 9861 10646 +785
- Partials 777 799 +22 ☔ View full report in Codecov by Sentry. |
Test Results 2 657 files ±0 2 657 suites ±0 5h 31m 12s ⏱️ +4s Results for commit 28fe7d7. ± Comparison against base commit c48af78. This pull request removes 63 and adds 63 tests. Note that renamed tests count towards both.♻️ This comment has been updated with latest results. |
|
Why do we put them in one package? Because we want to use default package method easily. |
|
This is a breaking change, too. If you need to extend and use some default privilege methods, it will be inconvenient. Conflicts won't be a big issue. I prefer not shading this. |
|
@jerqi I see. So how about another resolution, we do not add a uniffle pacakge name, instead, we add a class prefix with Uniffle. e.g. BTW, I'm open to keep it like it is now, we can merge this PR after we first encounter a class conflict issue involved by this. |
|
@jerqi I study celeborn, css(byteDance), shuttle(oppo) , just paste some thoughts from my point. All of them put the client class entry point and related classes under a specific package, they are celeborn/css/shuttle, but for uniffle, we put it into |


What changes were proposed in this pull request?
Make spark client uniifle class under org.apache.uniffle package to avoid conflict
Why are the changes needed?
(Please clarify why the changes are needed. For instance,
Fix: #1881
Does this PR introduce any user-facing change?
No.
How was this patch tested?