Enforce coding standards in all files of a project at build

I know there are some similar questions around in Stackoverflow, but they were either .Net related or didn't have any answer that helped us.

The case is as follows: with some friends we are starting an open source project. While setting开发者_运维问答 the foundations of the hopefully successful project, a question arose: how to enforce the code conventions of the project?

The reasoning is that being an open source project, if people starts reformatting the code as they like, the patches will become cluttered with changes due to formatting that will hide the real "value" of the patch. So we want something that forces users to abide to a specific formatting, breaking the build if they don't.

The project is using Struts 2 + Spring + Hibernate, using Maven 2 (thinking on moving to Maven 3). We know we can use "CheckStyle" to test the Java files, but this leaves some questions open that hopefully someone can answer:

• There is some tool to check the style of XML and SQL files, breaking the build if they don't abide to the rules?
• There is some tool that automatically reformats the source files (Java, XML, SQL) to the desired convention? Can ti be integrated with Maven somehow?

We could find Jalopy for Java files, but we would prefer a free tool (as far as we know, the latest version is paid one). And we still couldn't find anything for SQL/XML.

UPDATE: just to make it clear: I'm not asking about PMD, Checkstyle or these tools. I'm asking for tools that:

• Automatically format SQL, XML and/or Java files to a desired coding convention (4 spaces, etc)
• Detect SQL and XML files with the wrong format and break a build because of that.

The standard tools I would use for java are

• CheckStyle
• FindBugs
• PMD

All of these are capable of failing a Maven build when a certain threshold was reached.

But the question is of course: who runs those tools, and when?

My suggestion would be to get a Continuous Integration Server like hudson and configure it to run the maven checkstyle, findbugs and pmd goals (hudson has plugins to display graphs for all these tools), and you will always see who failed the build, because you can see who committed what between two builds.

It sounds to me like you're going along the route of creating an open source project and then giving commit access to all. I'd advise against this, whatever measures you try to put in place, someone stupid will come along at some point and sod the whole lot up.

Instead, I'd advise taking a different approach with commit access and handing it out only to people that prove they pay attention to the rules and restrictions you've put in place. They can generate patches, submit them to you and eventually if they're regular and trustworthy enough, you can hand out commit access.

One other point, something like Hudson may be of use here (it has a checkstyle plugin as well.) It won't prevent people committing crap code, but it can create a build and run checkstyle every so often, notifying people on a mailing list if someone screws up the code (either because it won't build or because someone's broken checkstyle rules.) Not foolproof, but this would enable you to keep an eye on things more easily.

Each of PMD, Checkstyle, Findbugs etc have Eclipse and other IDE plugins. You can also configure your IDE of choice to format according to the style you want, and then share this configuration (as a file) among members of the team.

I don't think you want your SCM server formatting files for you, otherwise after a check-in your local copy might be immediately out of date with whats in SCM. Everyone on the project would have to get used to doing an update immediately after a commit then, which sounds like a brittle process.

Instead, share your IDE configuration with the team (checking this config file in would be a good idea for what you want) and then fail the build if anyone violates the policy.

Yes, since eclipse, for example, has a build-in code-formatter, it could be possible that you may use the formatting-plugin to format all the java-code along a fixed configuration file, even without eclipse or any other GUI in a build process.