At the risk of pointing out the obvious, IDE configs are not just about
storing build settings. They are frequently ways to save developer hours.

Even if a file has nothing whatsoever to do with the build, it's worth
archiving if it saves new developers an hour of IDE setup, or if it
reduces confusion because of not understanding the tool (and let's face
it, Eclipse is about the worst when it comes to bad documentation).

My recommendation would be to find that one guy on the team that
everybody goes to for advice, and archive his configuration. It may not
be the most common, but it pays off the most in making his life easier
when he's helping out some other victim.

=Austin

Michael Hüttermann wrote:
> central project stuff should be managed by M2 only. Artifacts and
> dependencies should be independent on special IDEs. I do not like
> settings which cannot be reprocuded by the central integration system.
> If you talk about IDE configurations .. this is an interesting topic:
> IntelliJ IDEA introduced a new feature recently to have a central
> IntelliJ server which helps sharing all those developer workspace
> configurations. But: the single point of truth is inside the central
> integration build system .. and similar to not relying on individual IDE
> Checkstyle or whatever settings you want all those builds, audits .. IDE
> independent.
>
> Kind regards
> Michael
>
>
>
> Sean Dockery schrieb:
>
>> 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,
>>
>> ------------------------------------------------------------------------
>>
>> *From:* scm-patterns@yahoogroups.com
>> [mailto:scm-patterns@yahoogroups.com] *On Behalf Of *Steve Berczuk
>> *Sent:* Saturday, January 03, 2009 11:26 AM
>> *To:* scm-patterns@yahoogroups.com
>> *Subject:* [scm-patterns] IDE configurations: Primary or Derived Artifact?
>>
>> What are people's thoughts on how to treat IDE configuration files, as
>> compared to build script files in terms of sharing and version
>> management?
>>
>> Here's a concrete example to motivate the discussion:
>> - A team is using Maven as their primary build tool.
>> - Developers on the team as using various IDE, say IDEA, and Eclipse.
>> (The example is Java centric, but comments from those not in the Java
>> world would be helpful too :) )
>>
>> Should IDE project files be treated as primary artifacts, version
>> controlled and shared, or are they derived artifacts?
>> Some of the discussion points that come up are:
>> - It is possible to generate Eclipse and Idea files from Maven POMS.
>> And Both IDEs have the ability to keep their project files in synch
>> with the Maven POM files, so all dependency information can be stored
>> in the Maven Build.
>> - The maven build is the build of record.
>> - The IDEs can provide for enhanced warnings and errors for coding
>> style issues.
>> - It is possible to add support for errors and warnings as part of the
>> build.
>>
>> How do your projects treat IDE files? Do you version them like build
>> scripts and treat IDE warnings and errors the same way you treat
>> "Build" warnings and errors?
>>
>> (I have some thoughts, but would like to not say too much until there
>> is a discussion so as not to bias anyone :)) )
>>
>> Steve
>> --
>> Steve Berczuk | steve@... <mailto:steve%40berczuk.com> |
>> http://www.berczuk.com <http://www.berczuk.com>
>> SCM Patterns: Effective Teamwork, Practical Integration
>> www.scmpatterns.com
>>