Thank to everyone for comments. My thought was that the IDE configs
were secondary, and things that should not be versioned at all. It
sounds like a good compromise (there are people on the project who
feel strongly about the IDE configurations) would be:
- IDE files relating to build and path issues should not be versioned
since they are derived from the Maven POM. (this might have been an
issue even a year ago when Maven/IDE integrations were not quite as
good, but they seem reasonable now).
- IDE files relating to other settings (warnings, etc) could be
versioned. (But probably shouldn't :) )
- Any warning/error checking we want to do with the IDE should be done
as part of the build first, and replicated in the IDE as closely as
possible.

Now to think of how to justify this to those with strong opinions that
we should maintain both (actually 3 - M2 and 2 IDEs) :)

Thanks!

Steve

On Sat, Jan 3, 2009 at 8:30 PM, amaximov <anton@...> wrote:
> a quick hack that i've used in the past: have
> /users/<username>/eclipse directories and have folks store their own
> stuff there that they needed and symlink /.classpath, /.project and so
> on to the files in the individual user directory (or simply copy it
> over by hand).
>
> in addition, provide a common /users/template/eclipse/project.template
> and so on that people can copy and use as a basis.
>
> then add /.* to ignore list.
>
> you can replace a template with a maven target that can produce a
> basic set of files using its IDE integration.
>
> finally, use variables as much as possible in the IDE config files (as
> opposed to hardcoded paths).
>
> but of course it all depends on the project, its complexity, people
> involved, ides used, etc.
>
> -a
>
> On Sat, Jan 3, 2009 at 1:26 PM, Steve Berczuk <steve.berczuk@...> wrote:
>> 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@... | http://www.berczuk.com
>> SCM Patterns: Effective Teamwork, Practical Integration
>> www.scmpatterns.com
>>
>>
>
> ------------------------------------
>
> Yahoo! Groups Links
>
>
>
>



--
Steve Berczuk | steve@... | http://www.berczuk.com
SCM Patterns: Effective Teamwork, Practical Integration
www.scmpatterns.com