Jianbin and I discussed this on DingTalk last Friday. We agreed to apply Spotless to the entire codebase.
Please take a look 👀 Best Regards, Yongjun Hong On 2025/03/16 14:26:32 Min Ji wrote: > go ahead. > > Warm regards, > > Ji Min > > Yongjun Hong <dev.yongj...@gmail.com> 于2025年3月16日周日 21:54写道： > > > > Hello Jimin, > > > > I think that's a great idea.👍🏻 > > If there are no objections from other members, I'll proceed with the > > approach you suggested. > > > > Best Regards, > > Yongjun > > > > > > > Hi Yongjun, > > > Just quickly looked at the PR you mentioned – that's definitely a > > > hefty change! Considering the trade-offs, I think it'd be wiser to > > > limit its scope to only change files for now. Here's an idea: When > > > contributors submit PRs, let the workflow run Spotless formatting > > > specifically on the changed files. What do you think? > > > > > > Warm regards, > > > > > > Ji Min > > > > > > Yongjun Hong <dev.yongj...@gmail.com> 于2025年3月16日周日 21:12写道： > > > > > > > > Hello Jimim, > > > > This is a very insightful point. In fact, after applying Spotless to all > > > > files, 1,914 files were changed. As you mentioned, applying it to all > > > files > > > > at once can indeed shift line numbers, making it harder to match changes > > > > back to their original context. > > > > > > > > Currently, I see two possible approaches: > > > > > > > > 1. Apply Spotless only to changed files > > > > By implementing this method, Spotless will only be applied to the > > > modified > > > > code when each user changes the code. This will prevent a large number > > > > of > > > > changes from being made all at once. > > > > > > > > 2. Apply Spotless to all files > > > > This is the approach used by open-source projects like JUnit5, among > > > > others, that have already applied Spotless in the early stages. Since > > > they > > > > applied Spotless early on, they didn't need to consider situations like > > > > ours. > > > > > > > > However, after actually applying Spotless, most of the changes were > > > related > > > > to whitespace or import statements. > > > > Below is a link to a PR I created after applying Spotless to all files > > > > in > > > > my personal repository. > > > > - https://github.com/YongGoose/incubator-seata/pull/2 > > > > > > > > Best Regards, > > > > Yongjun > > > > > > > > > > > > > Hi Yongjun, > > > > > > > > > > Can Spotless only work on the change files instead of all files? Most > > > > > IDEs come with Git tracing plugins. These tools can show you > > > > > line-by-line history—like which commit last changed a specific line of > > > > > code and why it was modified. That’s super handy for untangling > > > > > complex code logic. But if you apply this to the entire codebase all > > > > > at once, it can mess up the traceability. Line numbers might shift > > > > > around, making it hard to match changes back to their original > > > > > context. Basically, you lose that precise 'who did what and where' > > > > > clarity. > > > > > > > > > > Warm regards, > > > > > > > > > > Ji Min > > > > > > > > > > Jiangke Wu <xingfude...@apache.org> 于2025年3月14日周五 16:55写道： > > > > > > > > > > > > Dear Yongjun, > > > > > > > > > > > > This is a fantastic proposal! 🎉 I wholeheartedly agree that > > > automating > > > > > > code formatting aligns perfectly with Seata’s goals of improving > > > > > > contributor experience and maintaining consistent code quality. Your > > > > > points > > > > > > about Checkstyle’s limitations (especially the lack of auto-fixing) > > > and > > > > > > Spotless’ actionable “apply” feature are spot-on. > > > > > > > > > > > > The community-friendly aspect you highlighted is crucial for our > > > global > > > > > > contributors. By reducing friction around formatting rules (even for > > > > > those > > > > > > unfamiliar with Alibaba’s specific guidelines), Spotless could lower > > > the > > > > > > barrier to entry and streamline collaboration. The JUnit reference > > > adds > > > > > > significant credibility—seeing a widely-used project successfully > > > adopt > > > > > it > > > > > > gives confidence in its feasibility. > > > > > > > > > > > > > > > > > > Best Regards, > > > > > > Jiangke Wu(xingfudeshi) > > > > > > > > > > > > > > > > > > On Sat, Feb 22, 2025 at 5:30 PM Yongjun Hong <dev.yongj...@gmail.com > > > > > > > > > wrote: > > > > > > > > > > > > > Dear Seata community, > > > > > > > > > > > > > > Checkstyle is a great tool for maintaining code formatting, but it > > > only > > > > > > > points out issues without automatically fixing them. On the other > > > hand, > > > > > > > Spotless provides an apply feature that can automatically format > > > the > > > > > code, > > > > > > > making it much more convenient to use.Since Seata is an > > > > > > > open-source > > > > > project > > > > > > > under Apache, developers from all over the world contribute to it. > > > > > While it > > > > > > > would be ideal if everyone were already familiar with Alibaba's > > > > > Checkstyle > > > > > > > rules, many contributors, including myself, may not be. > > > > > > > > > > > > > > With that in mind, adopting Spotless could be a good option. For > > > > > reference, > > > > > > > JUnit, a project I have contributed to multiple times, has > > > integrated > > > > > > > Spotless, and I found it to be very convenient. What do you think > > > about > > > > > > > using Spotless? > > > > > > > > > > > > > > Best regards, > > > > > > > Yongjun > > > > > > > > > > > > > > PS. Dubbo community is using the Spotless plugin. > > > > > > > > > > > > > > > > > > > > > > https://github.com/apache/dubbo/blob/cedc58316ddce533644aa627e5233711907c2e62/pom.xml#L172 > > > > > > > > > > > > > > Related document > > > > > > > - https://github.com/diffplug/spotless > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > > > To unsubscribe, e-mail: dev-unsubscr...@seata.apache.org > > > > > For additional commands, e-mail: dev-h...@seata.apache.org > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: dev-unsubscr...@seata.apache.org > > > For additional commands, e-mail: dev-h...@seata.apache.org > > > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@seata.apache.org > For additional commands, e-mail: dev-h...@seata.apache.org > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@seata.apache.org For additional commands, e-mail: dev-h...@seata.apache.org
