かなり複雑なマルチモジュールMavenプロジェクトがあります。Flexモジュール、GWTモジュール、Javaモジュール、および多数のWARモジュールがあります。これらのプロジェクトをEclipseにインポートするプロセスを単純化するために、これまで、関連するすべてのEclipseプロジェクトファイルをソースツリーに含めてきました。
ただし、これらのファイルが誤って変更されてチェックインされることがあるため、これは過去の問題の原因でした...したがって、他の開発者に問題を引き起こしていました。M2Eの出現と、インポート時にEclipseプロジェクトのセットアップを支援するためのコンフィギュレーターの新しいサポートにより、この戦略を再考しています。
一般的に、プロジェクトはこれらのEclipseファイルをSubversion / Git / etcに含めますか？
個人的には、プロジェクト構成ファイルをSCMに含めることはお勧めしません。.projectファイルには、相対パスまたは絶対パス、つまりURIが含まれています。これは、ユーザー間で非常に異なります。.projectファイルの仕様はここにあります。
トップレベルの答え：それは完全に好みの問題です:-)
個人的には、「内部」プロジェクト（他の開発者の環境をある程度制御できる）の場合、Eclipseファイルを含めますが、構成で全員が相対パスを使用するようにする必要があることに注意してください。（ライブラリパスがハードコーディングされているため、数か月ごとにビルドが中断されます。修正には数秒かかりましたが、面倒でした。）また、通常、Eclipseのコードフォーマットやコンパイラの警告などを多用しました。生活を楽にするための設定（たとえば、誰かの編集者がタブのフォーマットをめぐって争ったため、Subversionの巨大なチェックインはありません）。
ボーナスとして、新しい開発者を連れてくると、Eclipse Subversionチェックアウトシステムは、トランク/ブランチで.projectファイルを検出したときにプロジェクトを自動構成します。Eclipseを使用してビルドを管理する場合（たとえば、AntやMakeとは対照的に）、これは二重の勝利です。
より多様なチームに所属している場合（たとえば、Eclipseを使用して同種（原文のまま）ではない場合）、実際には、それらは「それほど」迷惑ではありません。私が取り組んでいる「共同」プロジェクトが1つあり、MicroSoft Visual Studio制御ファイルと.projectファイルでいっぱいのフォルダーがあり、それらをアドホックに同期する必要がありますが、少なくとも「2つだけ」のセットがあります。同期するそれらのファイルの。Subversionにそれらがなければ、開発者ごとに1つ存在することになります…</ p>
「ダミープロジェクト」を使ってプロジェクトファイルを保持することも聞いたことがあります。例えば
svn://someplace.nn/projects/MyProject/trunk —> source
svn://someplace.nn/projects/MyProject.control/trunk —> project control files
私が見た唯一の場所は、大きなGPLブランチと非GPLローカルのプロプライエタリプラグインの小さなリポジトリを持つプロジェクトでした…ほとんどのネットコラボレーターのように、GPLブランチには.projectファイルがありませんでしたEclipseを使用しておらず、プロジェクトファイルは内部（プライベート）Subversionサーバー上にあり、3番目のプロジェクトには独自のプラグインコードが含まれていました。（そして芸術のための4番目、音楽のための5番目…）
私が遭遇したほとんどすべての（作業）プロジェクトは、.projectファイルをSCMに保存します。主にビルダーなどがファイルに保存されているためです。したがって、すべての開発者はEclipseで一貫した構成を持っています。
ファイルにタブを配置することを主張する1人の開発者を除いて、すべてCheckstyleを使用しているシナリオを想像してみてください:-)。
.projectだけでなく、.classpath、.checkstyle、.settingsのすべてに適用されます。
注意しなければならない唯一のことは、プロジェクトで参照するすべてのものに、プロジェクトに相対的なパスがあることです。たとえば、checkstyle構成などです。これは、使用するすべてのものがおそらくSCMにも含まれることを意味します。しかし、これはすべてあなたのプロセスの一部であるため、これは利点ですよね？
使用されるIDEは多様であるため、上記は必ずしもFOSSプロジェクトに当てはまるとは限りません。
あなたはあなたのpomにmaven-eclipseプラグインを追加することを検討するかもしれません。したがって、開発者はソースコードをチェックアウトし、Eclipseプロジェクトをローカルでビルドして、ワークスペースにインポートできます。
また、一般的なeclipse（またはeclipseプラグイン）関連の構成ファイルがある場合は、maven-eclipse-pluginでも定義できます。たとえば、checkstyle.xml、codeTemplate.xml、codeFormatter.xml....これらのファイルをscmに保存することをお勧めします。