Hello Steve,

I avoid versioning anything (such as Eclipse project and classpath files) that can be generated from an authoritative source.  IDE meta-files which cannot be generated, such as Eclipse plug-in configuration files, need to be versioned appropriately to ensure a consistent developer environment.  When different development environments (Eclipse vs. IDEA, for example) need to be configured in a consistent manner, so some manual validation needs to confirm that changes in the Eclipse configuration are properly implemented in the IDEA configuration and vice versa.  By minimizing the number of IDE configuration files that are versioned, developers will have more freedom to use the IDE of their choosing.

One exception to this rule (off the top of my head) is caching a generated artifact that either is difficult or impossible to generate automatically (such as when GUI tool interaction is required), is expensive to generate (large and/or time-consuming), or changes very infrequently (automating and running the process to generate the artifact is far more time-consuming that it is worth, or the artifact never or almost never changes after it is generated).  Cached artifacts need not be versioned, however, as it is possible to store such artifacts on a network drive or in a Maven repository.  If one does not have a Maven repository or similar facility at one’s disposal, it is often convenient to use the revision control repository to cache generated artifacts.  Backup strategies, security policies, and network topologies would bias the decision of where to store cached artifacts.

With respect to enforcing coding standards, I would avoid relying on the IDE warning facility exclusively.  Those facilities cannot be used to fail a build.  Instead, I would look for a command line tool that has an IDE plug-in option (such as Checkstyle).  This allows you to capture metrics from the command line tool and fail the build appropriately while still enjoying the benefits of IDE integration.  If the configuration of the IDE plug-in must be maintained separately from the build configuration, I would explore the possibility of being able to generate one from the other; failing that, manual validation may be required to confirm that the build configuration and the IDE configuration were consistent.  Perhaps if you could not generate one configuration from the other, you might still be able to automate the validation such that the build failed when the configurations were inconsistent.

Kindest regards,