First off, your team needs to pick a formatting convention and stick with it. You need to come to an agreement and have everyone stick to it so you don't have people fighting over what things should look like. This should not just be something you do on your own.
As for your real question. Formatting code is not a bad thing. What is bad is making major formatting changes in the same commit as code changes. When your team comes to consensus about how things should be formatted, make one pass thru the code and format everything. Check that in by itself. The commit message will make it clear that the changes are just white space and not functional. Then when you need to make functional changes, they are in a different commit so they can be clearly seen.
I currently work at a place where a standard code format is enforced and the code is automatically formatted when saving the file, just like you are about to do. As a new member of the company I found that the common formatting rules gave me a warm and fuzzy feeling that "these guys know what they are doing", so I couldn't be happier. ;) As a related side note, with the common formatting rules we also enforce certain, rather strict compiler warning settings in Eclipse, with most of them set to Error, many set to Warning, and almost none set to Ignore.
I'd say there are two main reasons to enforce a single code format in a project. First has to do with version control: with everybody formatting the code identically, all changes in the files are guaranteed to be meaningful. No more just adding or removing a space here or there, let alone reformatting an entire file as a "side effect" of actually changing just a line or two.
The second reason is that it kind of takes the programmers' egos out of the equation. With everybody formatting their code the same way, you can no longer as easily tell who has written what. The code becomes more anonymous and common property, so nobody needs to feel uneasy about changing "somebody else's" code.
Those being the main reasons, there are others as well. I find it comforting that I don't have to bother myself with thinking about the code formatting, as Eclipse will do it for me automatically when I save. It's care-free, like writing documents with LaTeX: it's formatted afterwards and you don't have to worry about it while writing. I have also worked in projects where everybody has had their own styles. Then you have to think about stupid and meaningless issues such as if it's OK to modify somebody else's code in your own style, or if you should try to imitate their style instead.
The only argument against common code formatting settings that I can think of for your case is that it's apparently an already ongoing project, so it will cause lots of unnecessary changes in all the files, messing up the actual file histories. The best case scenario is if you can start enforcing the settings right from the beginning of a project.
Best Answer
Strict code formatting rules are useful when several developers work on the same code using a version control system. Merging can be a pain if different developers have different formatting rules as the same code would look different for the merging tool.
Eclipse (or any good IDE for that matter) has code formatting rules that can be customized in the preferences section (Java > Code Style > Formatter). Choose what you like best, but have also a look at the Java standard code conventions. Many open source projects also have their own code conventions that can be enforced with the Eclipse formatter.
In addition there are standard tools like CodeStyle, PMD and Findbugs that enforce additional rules and help avoid common (low-level) anti-patterns and mistakes.