>
When you assume that JDT/Core committers use save actions for code clean-up,> this assumption may not be shared with fellow committers.
Those save actions are part of the JDT core project settings. Not only do they happen by default, they are also extremely difficult to disable or circumvent since the "Save Actions" preference page for the JDT core project doesn't seem to work.
Since the they happen by default and are very hard to turn off, I think it's reasonable to assume everyone is using them. Here's a challenge: Try to make a trivial edit in org.eclipse.jdt.internal.core.ClassFile and save it without rewriting line 35 which says:
import org.eclipse.jdt.core.*;
It rewrote the line on you when you saved, right? No problem, you can edit the change prior to submission in the compare editor. Great. The compare editor tells you the changes have been removed. Sadly, they're not actually gone. If you close and reopen the compare editor after saving, the changes are back. Okay, try flipping a bunch of settings in the project properties for the JDT core project to disable all post-save actions. Now reopen the file and try again. It's still rewriting that line. There's a lot of combinations, though. Start flipping different combinations of options on and off and repeat the above steps. (Full disclosure: I once discovered a combination that actually disabled the post-save actions, but I can't remember what it was and can't replicate it)
Fighting the post-save actions is *extremely* frustrating.
...but I know how much you like those wildcard imports, so I try to make an effort to edit every file I commit in Sublime Text immediately before committing to git. I manually undo all the edits done by the post-save actions, but this is also time consuming. It probably takes me as long as your problematic merge took you, above, and I need to do it on every single commit. Evidently, a few slipped through and I'm sorry about that - but this workflow is awful.
My setup isn't unusual. I literally just run the Oomph installer, select the JDT project and start coding. I'm using the defaults for my post-save actions and haven't tweaked them in any way (except when I've created a workspace specifically for the purpose of trying to disable them, as described above).
> If you wish that the team should change its habits, then you need to convince the team that this is a worthwhile change
I like the automatic cleanup tools, but I don't like them enough to want to convince the team to change their workflow. What I strongly object to is the fact that the cleanup tools are enabled by default, they're really hard to disable, and we simultaneously have coding conventions banning their use. We either need to disable the tools by default or permit their use in our code.
- Stefan
