web-dev-qa-db-ja.com

Javaプロジェクト：.classpath .projectファイルをリポジトリにコミットする必要がありますか？

.projectファイルと.classpathファイルをチェックインする必要がありますか？

私の友人は、移植性を保証するために.Javaファイルとbuild.xmlだけをチェックインするべきだと言ってくれました。 「.classpathを使用すると、異なる環境での移植性が大幅に低下します。projectは完全にローカルのEclipse設定です」

私は彼に同意しますが、部分的には同意します。

-.projectファイルをチェックインしないと、開発の効率が低下します（ディレクトリからプロジェクトコードを単純に「インポート」することはできません）。

-build.xmlが慎重に記述されている場合、.classpathファイルをチェックインしなくても問題ありません（？）.

誰かがここで彼らの経験を共有したいですか？

javaeclipseantclasspathversioning
52
sean

.projectと.classpathのチェックインに問題はありません。 build.xmlが両方のファイルを作成できない場合は、そうします。あなたが言ったように、新しいEclipseワークスペースを作成しようとするときにこれらのファイルを見逃すのは不快です。

.classpathをチェックインする前に、絶対パスが含まれていないことを確認してください。テキストエディタで相対に変換します。

編集：またはさらに良いことに、@ taylor-leeseがコメントしたように、他の方法では絶対パスでEclipseクラスパス変数を使用します。

25
tangens

.classpathファイルをチェックインする際に注意すべきことの1つは、プロジェクトの外部でファイルを参照しないようにすることです。 Eclipseはこれらのファイルの場所を完全なファイルパスで保存するため、他の開発者がこれらのファイルをまったく同じ場所に置くようにする必要があります。

10
MikeTheReader

このようなすべてのファイルの重要な問題は、「自動的に再現できるか」ということです。そうでない場合は、ソース管理にチェックインしてください。

この場合、m2Eclipseとそれらを生成するEclipseプラグインを備えたmavenを使用しているのでない限り、私は「はい」と言います。

7
Dominic Mitchell

私の2セントでは、それを悪い習慣として評価します。プロジェクトはIDEに関連付けるべきではなく、特にIDEの特定のバージョンに関連付けるべきではありません。

Eclipse構成ファイルをチェックインすることは、より単純で短期的なプロジェクトではうまく機能する可能性があります。 IDEバージョンが変更され、プロジェクト構成ファイルは変更されないため、数年かけて開発された大規模なプロジェクトの場合、これにより一般に手間がかかります。Eclipse2.0で2年前のブランチをチェックインすることを想像してみてください。いくつかのカスタマイズされたライブラリーとm2e統合を備えたEclipse 4.3の構成ファイル...まったく面白くない...

6
Nick G.

私はEclipse設定ファイルを本当に知りませんが、IntelliJを使用すると、それらのファイルはOSに依存しないため、移植性が損なわれることはありません。あなたのシステムへのフルパスでライブラリを定義しない限り（それはかなり危険/愚かでしょう）。

設定を共有すると、誰もがプロジェクトで同じ条件（プラグイン構成、エンコード、プロファイル[intelliJ]）で作業することが確実になり、これは本当に良いことです。

いくつかのEclipseファイルがここにあるときは気になりませんし、いくつかの隠しファイルがそこにあるだけのときは、他の開発者を気にすることはないはずです。

3
Colin Hebert

.projectと.classpathをチェックインします。 ProjectSetを使用すると、単一の「インポートチームProjectSet」で複雑なワークスペースをチェックアウトできます

3
Thorbjørn Ravn Andersen

.projectファイルをチェックインしないと、開発効率が低下します（ディレクトリからプロジェクトコードを単純に「インポート」することはできません）。

この問題では、新しいプロジェクトの作成と既存のソースのインポートを選択できます。

IDE .projectのような特定のファイルに関する問題の1つは、他の開発者が別のIDEを使用してプロジェクトを開発したいため、別のタイプのプロジェクトを追加する可能性があることです。これにより、リポジトリが乱雑になります。

2
mhshams

.projectと.classpathをチェックインしたいと思います。

これは、このプロジェクトが複数の開発者によって共有されている場合に役立ちます。開発環境のセットアップが簡単で高速になります。これを、Eclipseを使用する任意のシステムに既存のプロジェクトとしてインポートするだけです。

ここで注意が必要なのは、クラスパスはプロジェクトに対する相対パスであるためです。

1
YoK

私はよく似た、より一般的な質問をします。問題は本質的に：

  • meに対してどのファイルをコミットしていますか？
  • othersに対してどのファイルをコミットしていますか？
  • →「バージョン管理」の両方の目的をどのように組み合わせることができますか？

私はこれについて議論することを提案しました there 、問題の詳細と興味深い解決策を見つけるかもしれません:)

私が一番好きなのはgit submodule：.projectファイルetc。プライベートコミットリポジトリ内。そして、あなたの最終的な、純粋な、不可欠なsrcプロダクションをきちんとしたsubmoduleナゲットにしてください：公開レポ。

project/ # root module
|   .git # private repo
|   .project
|   .classpath
|   momsNumber.txt
+---src/     # submodule
|   |   .git # public repo
|   |   main.Java
|   +---package/
|   |   |    Etc.Java

とにかくそこを参照してください。

1
iago-lito

.classpathファイルと.projectファイルをリポジトリにチェックインする問題はありません。これは、Eclipseを使用する開発者がより速く進むのに役立ちます。

警告：.classpathファイルが、プロジェクトでリポジトリにチェックインされているか、または自動的に取得できるアーティファクト（mavenアーティファクトなど）のみを参照していることを確認してください。

0
Eugene Ryzhikov