JavaプロジェクトをEclipseプロジェクトの形で継承しました。 （V7へV6から）Tomcatの設定を変更した後、SubclipseのはEclipseで変更されたファイルをコミットする必要があります
は、彼らが私のチームメンバーを助けるか、それが彼らのワークスペースを台無しだろうコミットでしょうか？
これに対するベストプラクティスアプローチは何ですか？
一般的に言えば、ビルドに貢献するすべてのものをチェックインし（変更後にコミットする）、完全に再ビルドして再生成することはできず、ワークステーション固有です。
これは、フルビルド時に再生成されたすべてを除外して、チェックインされていない（および提供されていない）ものをすべて除外する必要があることを意味します（このステートメントの意味は、ビルドプロセス/プロシージャーによって異なります）。チェックイン）。
これはまた、ファイルパスやユーザー設定などのワークステーション依存のものについて質問内のすべてのファイルを調べる必要があることを意味します。ワークステーションやユーザーに依存しないものがある場合は、その特定のファイルをコミットすることに何も問題はありません。たとえば、.classpathにはファイルシステムのパスが含まれていてもかまいませんが、ワークステーションに依存しないライブラリ名が含まれていて、そのパスが他の場所で定義されている場合もあります。 –
@ Sergey Tachenov：はい、これは私の意図していたものです。「このステートメントの意味は、ビルドプロセス/プロシージャーによって決まります。 – TheBlastOne
すべてをチェックして、ファイルがすべてパスに依存していないことを確認しました。私は、Eclipseではすべてがパスに依存しないか、または依存していると思っていましたが、両方ともではないと考えました。 –
これらのファイルは、プロジェクト上の他の人の作業スペースを台無しにしてしまうので、無視してください。
これらを無視すると、私はいつも好きなあなたのプロジェクトをきれいにすることができます。
Plsは何かをdownvoteするときに説明を提供します。 – fmucar
私はダウンボートをしませんでしたが、私はdownvoterが "クリーナー"はあまりにも漠然としていると思っています。典型的な初心者の状況：あなたは試して、ぶつかる。 @cgratgnyを続けて、それから学ぶと、あなたのポイントバランスはすぐに爆発するでしょう。この初期の学習曲線に挫折しないでください。正常と見なすことができます。 – TheBlastOne
コメントありがとう、@ TheBlastOne。私は試していたことを知っています。彼らが提供するソリューションで他の人ほど雄弁ではありません。 – Chris
これらのファイルには環境固有のパスが含まれる可能性があるので、私はそれらをチェックしないことをお勧めします。私の現在のプロジェクトでは、プロジェクトを作成するためにantスクリプトを使用しています。
パスとしてこれらのファイルをコミットしない方が良いです/異なるワークステーションで設定が異なる場合があります。
これを解決するには、いくつかのビルドツールを使用することができます。 （例えば、Maven）
チームメンバーのいずれかがEclipse（他のIDEを使用しています）を使用していないかのように、それらのファイルは意味がありません。
誰もが異なるIDE設定をコミットする場合、どのような混乱が起こるか想像してください。
編集：
詳細説明;
私は、NetBeans、Eclipse、IDEAを使用しているチームで働いています...本当に長い間、実際にIDEを変更するオプションではありません。その人の生産性にのみ影響します。
人が自分のIDEに慣れると、shorcutsを学び、いくつかの機能（refactor/generate getter setter/implement override required methods ....）を探す場所を知っているので、他のIDE物事をより困難にし、全体のプロセスを遅くします。 IMHOと柔軟なコードベースを持つ私の経験から、常に良いです。私は日食の男ですし、おそらく他のIDEと一緒に仕事したくないのですが、私は事実をより早く/簡単にするたくさんのショックカットを知っています。
すべてのIDEファイルは、おそらくほんの数回のクリックでIDE自体によって自動生成されます。
私の現在のプロジェクトには3人の開発者がいて、それぞれ別々のIDE（Eclipse）、NetBeans、IDEAを使用しています。私はレポからソースをチェックアウトすると、Eclipse用の意味がないIDEAまたはNetBeans設定ファイルを見たいとは思わない。同様に彼らのために。
+1はワークステーション固有のものです。その代わりに、私は自分自身の答えにこの側面を加えました。 – TheBlastOne
-1どうして？ – TheBlastOne
"は誰ですか？なぜですか？ :)完全な質問文は私に質問が何であるかを理解させるでしょうか？ – fmucar
はい、パスが絶対パスではなく作業領域内で相対的であることを確認してください。これらのファイルをワークスペースに置くことで、チームのメンバーはあなたと同じ環境で作業することができます。また、新しい開発環境をもっと簡単に設定することができます。ソース管理からチェックアウトし、Eclipseで「インポート...既存のプロジェクトをワークスペースに使用」
@adamdunneが述べたように、パス。ただし、変数を使用したり、ワークスペース内のプロジェクトからjarファイルのみをインポートしたりしないで、パスをワークスペース内で相対的に指定するよう注意している場合は、問題ありません。私のワークスペースでは、これらのファイルをチェックインし、開発者の設定に関する問題が大幅に少なくなっています。それ以来環境。
+1は、ワークステーション固有の設定詳細を取り除く方法を示します。 – TheBlastOne
私たちはそれを（「インポート...>既存のプロジェクトをワークスペースに」）行いました。これが私が最初に質問した理由です。現在私のチームはトレーニングモードにあり、私はプロジェクトのライフサイクルのためにできるだけ多くのベストプラクティスを採用したいと考えています。 –
私は私たちが.classpathファイルをコミットするプロジェクトで働いています。すべての開発者が同じものを使用することは非常に便利です。ワークスペース内の依存関係のみを使用する場合、このファイルは相対パスを使用するため、マシン。このファイルをビルドする必要はないかもしれません（例：ant）と同期させるのが非常に便利です。これに対して私はチェックしませんorg.eclipse.core.prefs店（私の知る限り）プロジェクト固有が、開発者の個人的な好みで
。私はまだ仕事をdidn'tファセットを有する
本当のプロジェクトなので、私は教えてくれません。しかし、一般的には、ファイル内の情報や作業方法に依存していると思います。
あなたが不明な場合は、試してみてください。これらのファイルに一貫性がない場合は、これはヒントですが、完璧な方法ではないかもしれません。
>>わからない場合は、試してみてください。 <<そしてチームの残りの人たちはすぐにその経験を楽しんでもらいましょう。これらのファイルに一日中矛盾が生じた場合は、残りのチームもそれらのファイルを入手して、ビルドに成功したというヒントです:) – TheBlastOne
>>これらのファイルに一日中矛盾が生じた場合、これはヒントです"完璧な方法ではないかもしれない。" Duke Nukemは言うだろう： "Hehehehehe、何が混乱している。 :) – TheBlastOne
org.eclipse.core.prefsには、Javaコンパイラのソースとターゲットのバージョン、警告/エラーの設定などが格納されています。 –
これらのファイルは、開発者間で構成を共有するのに非常に役立ちます。代わりにMaven（既存のプロジェクトにとっては大きな仕事）を使用するか、プロジェクトを構築するまで半減するステップバイステップの指示と新しい開発者を絶えず時代遅れにすることです。
ただし、これらの設定が移植可能であること、つまりローカルパスが含まれていないように注意する必要があります。これは、ワークスペース内の相対パス、eclipseパス変数、およびユーザー・ライブラリーを使用して行うことができます。
私は別のコメントでそれを書いた、私は日食はすべての相対的または絶対的なパスを持っていたと信じていますが、両方ではないと信じていました。これが私がこの質問を投稿した主な理由です。これと同様のアドバイスに基づいて、私はすべてのファイルを見直し始め、それぞれのファイルで何が起こっているのかを見ました。どうもありがとう。 –
@dimitris：両方を持つことは間違いありません。たとえば、プロジェクトのビルドパス（.classpathファイルにエントリが追加される）にJARを追加する場合、オプション "Add JARs"があります。このオプションを使用すると、ワークスペース内からファイルを選択して相対パスを生成し、任意のファイルを選択して絶対パスを生成する「外部JARの追加」を使用します。 –
一般的に、ユーザーの設定や、Eclipseやプラグインが再生成できるプロジェクトの詳細を含むファイルをコミットしないでください。
しかし、状況によっては少しばかりです。たとえば、.classpathファイルは、をEclipseビルドパスの主なソースにすることができます。例えばMavenを使用するのではなく、プロジェクトツリーにJARファイルがある場合。 （Mavenの場合、m2eclipseプラグインはPOMファイルの依存情報から.classpathファイルを生成するため、ファイルをチェックインしないでください）。
また、ファセットのいくつかは境界線です。たとえば、JSPとJavascriptのプロジェクトでは、破損したバリデータを無効にするために、ファセットプロパティを変更することが不可欠であることがわかっています。これらの変更を個人的な好みとしてではなく、プロジェクトの一部として扱う良いケースがあります。
個人的な好みからのグループ/プロジェクトの選好の分離は、（IMO）Eclipseが重大な欠点を持つ1つの領域です。
他のIDEは優れていますか？その場合はどうすればよいですか？私は日食はそうだと思う：重要なプロジェクト設定をプロジェクトディレクトリ内のテキストファイルとして持つことは素晴らしいことだ。さまざまな形式のファイルに分散させるのはあまり面白くないのです。 –
@Michael - * "他のIDEは良いですか？" - 真剣にも、わかりません。そしておそらく、あまりにも難しい/修正が遅すぎるものの1つです。 –
http://stackoverflow.com/questions/116121/do-you-keep-your-project-files-under-version-control/119377#119377、またはhttp://stackoverflow.com/questions/2024307をご覧ください。/what-should-be-commit-to-the-eclipseワークスペース、または（より一般的な）http://stackoverflow.com/questions/1880817/what-to-put-under-version-コントロール – VonC
うわー。私はちょっと見ようとしました。私は自分の質問が2つか3つに分かれて、それぞれが適切な反応を得ることができると思う。私は最高の答えがあなたのコメントになると信じています:-) –