web-dev-qa-db-ja.com

.classpathと.project-バージョン管理にチェックインするかどうか

依存関係のツリー内の複数のモジュールで構成されるオープンソースJavaプロジェクトを実行しています。これらのモジュールはすべて、Subversionリポジトリ内のサブディレクトリです。私たちのプロジェクトの初心者にとって、Eclipseですべてを手動で設定するのは大変な作業です。

すべての開発者がEclipseを使用しているわけではありません。それにもかかわらず、私たちは.classpathと.projectファイルをチェックインして、初心者が始めるのを助けることを検討しています。これはいいアイデアですか?それとも、それらのファイルで絶えず競合することになりますか? Eclipseでプロジェクトを簡単にセットアップできる代替方法はありますか?

84
amarillion

プロジェクトファイルをバージョン管理下に置いていますか? 」で述べたように、決定的にはい

「ロードして、セットアップして、行ってください。」

しかし...これは、ビルドパス相対パスのサポートである最近のEclipse3.5設定に対してのみ実際に当てはまります。

Build path supports relative paths


そして、Eclipse3.6の方が良いでしょうパス変数の相対パスをサポートLinked Resources

path variable with relative path
(3.6M5以降)

63
VonC

間違いなく、プロジェクトファイルをSubversion経由で配布するのは一般的にひどい考えです。特に誰かが奇妙な方法でそれらを変更するかもしれないので。プロジェクトのドキュメントの適切なページは、はるかに優れたアイデアです。このプロジェクトには、多くのモジュールと複雑なセットアップもあります。各ポピュラーIDE-IntelliJ、Eclipse、NetBeansでプロジェクトを開始する方法を説明した合流ページを設定しました。 SubversionのREADMEファイルには同じ情報が含まれています。

17
Bozhidar Batsov

私は投票しませんが、それは私が一般的にこれらのファイルをmavenから生成するためです

9
Goibniu

ファイルに絶対パスや、単一の開発者の環境に直接結び付けられるその他のデータが含まれていない場合、ファイルをSubversionにチェックインすることをお勧めします。

ファイルに絶対パスなどが含まれている場合は、READMEの方が適しています。

5
vkraemer

私の経験では、純粋にローカルな設定が関係する限られた場合を除いて、すべてがソース管理にあるべきです。ソース管理の法則では、押し込まれたものはすべて、引き出した人によって機能することが期待されます。残念ながら、Eclipseはこのようなものを.classpath

    <classpathentry kind="con" 
      path="org.Eclipse.jdt.launching.JRE_CONTAINER/org.Eclipse.jdt.internal.launching.macosx.MacOSXType/Java SE 7"/>

したがって、私のMacではこれが機能し、Macの誰かが同じJREを持っているかもしれませんが、これは他の人には機能しません。

また、これを回避する簡単な方法はありません。 Eclipseは常にそれを追加します。バージョン管理が必要なlibフォルダーにはサードパーティのJARがいくつかあるため、そこに.classpathファイルが必要です。 。管理対象システムに移行していますが、管理対象+管理対象外の依存関係がチェックインされたままです。これは、すべての開発者が2つのディレクトリが.classpaths。ただし、プルするたびにJREを修正し、コミットするたびに.classpathを変更するよりも優れています。

Eclipseはあなたのために他のいくつかの素晴らしいことを行います。通常、.projectファイルはインスタンス間で同じなので、それを含めます。しかし、Eclipseのソース管理の最大の利点は、実行構成設定です。 [実行構成]ダイアログの[共通]タブで、構成を保存して、同僚が[デバッグ]および[実行]のお気に入りリストに表示されるようにします。私にとっては、.launchファイルは.settingsディレクトリ。すべて使用できます。

だから私は言う:.settingsディレクトリーは、起動構成のソース管理に入ります(* .prefsを除く)

.classpath外出します

.projectが入ります。

5
Zak Patterson

これらのファイルをチェックインして、新しいユーザーができるだけ簡単に開始できるようにします。ユーザーは、せいぜいプロジェクトをチェックアウトし、余分な知識がなくてもプロジェクトを実行できる必要があります。このファイルの場合、ルールはプロジェクト内の他のファイルと同じです。取り扱いには注意してください。ソースコードには絶対パスを配置しないでください。構成ファイルには絶対パスを配置する必要があります。

プロジェクトが最初から実行されるようにファイルがチェックインされている場合、それらを変更するための大きな力はないはずです。

5
Arne Deutsch

はい、必ずチェックインしてください。ただし、パスの依存関係を文書化し、可能であれば絶対パスを避けてください。

チェックインしない場合、プロジェクトをチェックアウトする人はすべて、これらの設定をすべて再作成する必要があり、これは迷惑であり、エラーが発生する可能性があります。

一部の複雑な設定は、これらのファイルを生成するためのスクリプトによって適切に処理される場合がありますが、通常はチェックインする方が適切です。

2