40

新しい Java プロジェクトの最初のコミットをチェックインする予定です。私は Eclipse Ganymede を使用しており、一連のプラグインによって作業が少し楽になっています。

以前、私は Eclipse プロジェクト全体がチェックインされたプロジェクトに参加していました。チェックアウト後にプロジェクト設定を取得するのは非常に便利です。ただし、このアプローチにはまだ問題がないわけではありません。

  • 一部の Eclipse 構成ファイルは (私が Eclipse Europa を使用していたときから) ユーザーの操作なしで変更され、コミットを行うときに変更されたように (対話的にではなく、変更されたように) 表示されるのではないかと強く思います。
  • 各開発マシンに固有の設定と、プロジェクトのすべての開発者にグローバルな設定があります。これらを別々に保つのは大変でした。
  • Eclipse のバージョンが他と異なると、Eclipse が怒ってプロジェクトの構成を台無しにしてしまうことがあります。もう 1 つのケースは、更新されるように形式を変更することです。コミットすると、他の構成が台無しになります。

この特定のプロジェクトでは、プロジェクト ファイルをコミットしない別の理由があります。

  • 後でプロジェクトに参加する NetBeans を好む開発者がいるかもしれません。ただし、彼らは今後数か月以内に参加しません。

これをどのように整理しますか？何をバージョン管理にチェックインし、何を外部に保持しますか? この種の状況でのベストプラクティスは何だと思いますか?

4

12 に答える 12

21

少なくとも.projectおよび.classpathファイルをチェックインする必要があります。チームの誰かが外部 JAR の場所をハードコーディングしている.classpath場合は、壁に押し付けて撃つ必要があります。私は Maven を使用して依存関係を管理していますが、maven を使用していない場合は、一貫した命名規則で外部 JAR 用のユーザー ライブラリを作成する必要があります。

あとはプラグインごとに考えていく必要があります。たとえば、私はSpringで作業しているので、常にチェックインし、.springBeansCheckStyleについても同様に、常に.checkstyleプロジェクトをチェックインします。

フォルダー内の構成に関しては少し複雑になり.settingsますが、プロジェクトのデフォルト設定を変更してチームの他のメンバーと共有したい場合は、通常、次をチェックインします。

  • .settings/org.eclipse.jdt.ui.prefs - インポート順序の設定が含まれています
  • .settings/org.eclipse.jdt.core.prefs - コンパイラ バージョンの設定が含まれています

一般に、プロジェクトの設定を変更せずに Ganymede がファイルを変更していることに気付いたことはありません。

于 2009-01-15T00:49:54.290 に答える
9

ライフサイクル全体がIDEの外にあるように、mavenを使用することをお勧めします。コマンドラインでEclipseプロジェクトを簡単に作成でき、Eclipseでない場合は何でも使用できます。癖がありますが、依存関係とビルド管理に関しては多くの苦味を取り除きます。

于 2009-01-15T12:10:49.220 に答える
7

私たちの世界では、Eclipse プロジェクト全体と、並行しているが別の Netbeans プロジェクト全体をチェックインします。これに対する私たちの動機は、完全に「チェックアウトを行った後、すぐに機能的な構成が欲しい」ということに集中していました。これは、いくつかの作業を行う必要があることを意味します。

  1. プライマリ IDE ごとに実行可能な構成を作成します (人々は好きなものを好みます)。これには、メイン クラス、作業ディレクトリ、VM パラメータなどが含まれます。
  2. 関連するすべてのシナリオに役立つ起動スクリプトを作成します。
  3. チェックアウトに時間がかかりすぎないように、編集済みのデータセットを作成します (これは大きなプロジェクトです)。

この哲学は、私たちの新入社員が Subversion から Eclipse へのプロジェクトをチェックアウトし、大騒ぎせずに (小さな) 実際のデータ セットを使用して機能するシステムをすぐに実行することができたとき、現金 (または少なくともそれよりも価値のある労働時間) の価値がありました。または彼の側で気にします。

フォローアップ: 「新しい人の生活を楽にする」というこの哲学は、彼が IDE を変更したときに再び報われました (彼はかなり長い間 Eclipse を使用した後、Netbeans を試すことにし、しばらくそれを使い続けることにしました)。構成はまったく必要ありませんでした。彼は、Eclipse が指していたのと同じディレクトリーで Netbeans プロジェクトを開いただけです。切り替え経過時間：約60秒。

于 2009-01-15T23:11:07.920 に答える
6

私は物事が人間によって行われたことをチェックインするだけで、生成されたものは（自動的に生成されたかどうかにかかわらず）簡単に再生成され、変更される可能性があります（あなたが述べたように）。これに対する唯一の例外は、生成されたファイルが難しい場合です (多くの人間の介入が必要です;))。このようなことは、実際に何らかの方法で自動化する必要があります。

于 2009-01-15T00:23:51.207 に答える
4

プロジェクトを maven などのビルド システムに移植してみてください。使用するすべてのマシンでプロジェクトの同じ経験を得るために必要なすべてが含まれています。

すべてのプラグインがあります。日食プラグインのように。「mvn eclipse:eclipse」と入力するだけで、プラグインがすぐに使える Eclipse プロジェクト全体を生成します。

あなたの質問に答えを与えるために。開発サイクルのどの時点でも、プロジェクトで使用されていないファイルをチェックインしないでください。つまり、Eclipse プロパティなどのメタデータ ファイルを SCM にチェックインしてはいけません。

于 2009-02-05T16:48:44.253 に答える
3

いずれにせよ、.project、.classpath、および同様のファイルがどの Eclipse ユーザーのマシンでも同一である場合にのみ、チェックインするのが好きです。(他の IDE を使用している人は、関係なくプロジェクトをチェックアウトしてビルドできるはずですが、その問題は、Eclipse のみのファイルをチェックインするかどうかとは直交しています。)

プロジェクトで作業している別のユーザーが、.project または .classpath またはその他のファイルに変更または微調整を加えたい場合は、それらをソース管理にチェックインしないことをお勧めします。長期的には頭痛の原因となるだけです。

于 2009-01-15T00:36:49.340 に答える
1

Netbeans 6.5には、変更をNetbeansからEclipseに同期することになっているEclipseプロジェクトのインポートが改善されています：http ：//wiki.netbeans.org/NewAndNoteWorthyNB65#section-NewAndNoteWorthyNB65-EclipseProjectImportAndSynchronization

于 2009-01-19T15:01:58.237 に答える
1

私たちの場合、すべての開発者がプロ​​ジェクト ワークスペースを簡単に作成できるように、プロジェクト ファイル (.project および .classpath) をチェックインしていました。共通の設定ファイルとチーム プロジェクト セットもソース管理に配置されているため、ワークスペースの作成は、設定のインポートとチーム プロジェクト セットのインポートと同じくらい簡単でした。これは非常にうまく機能しましたが、全員が一貫した環境を持っていることに依存しているため、基本的なワークスペースが作成された後にカスタマイズを適用する必要があります。

大部分はまだこれを行っていますが、現在は Maven が使用されているため、依存関係の管理は代わりに Maven を介して処理されます。情報の競合を避けるために、.project と .classpath はソース管理から削除され、チーム プロジェクト セットをインポートする前に Maven ゴールを介して生成されるようになりました。Maven 構成に基づいて IDE 固有の部分を生成するためのスクリプトが必要なだけなので、これによりさまざまな環境を簡単に使用できます。

PS-ただし、メンテナンスを容易にするために、全員が同じ環境を使用することを好みます。それ以外のことは、必然的に誰かのフルタイムのメンテナンスの仕事になります。

于 2009-01-15T15:39:41.607 に答える
1

XML プロジェクト ファイルを持つ IntelliJ を使用します。それらは頻繁に変更され、必要に応じて簡単に再作成できるため、チェックインしません。

JAR ファイルをチェックインしません。私はそれらをMaven 2のような別のリポジトリに保管しています。

WAR、JAR、javadoc、その他生成可能なものはチェックインしません。

SQL とスクリプト、Java ソースと XML 構成をチェックインします。

于 2009-01-15T00:21:17.623 に答える
1

あなたが言及した欠点のために、バージョン管理システムによって実際のプロジェクトファイルを無視することをお勧めします。

プロジェクト設定にアクセス可能にするメリットがある十分な一貫した情報がある場合は、それを Eclipse が特別とは見なさない場所にコピーします。 Eclipse が注意を払う場所)。実際のプロジェクト ファイルを制御されたものから分離しておくと、同期が失われる可能性が十分にあります。それらを同期させておくことができます）

于 2009-01-15T00:33:47.240 に答える
0

しないでください。プロジェクトのソース コードのみをチェックインします。

于 2009-01-15T00:22:53.487 に答える
0

への応答として:

「各開発マシンに固有の設定と、プロジェクトのすべての開発者向けのグローバルな設定があります。これらを区別するのは困難でした。」

Eclipse では、ローカル設定を管理しやすいようにいくつかの方法を提供しています。 /stable/index.jsp?topic=/org.eclipse.platform.doc.user/concepts/concepts-13.htmプロジェクトをビルド/実行する前にどの設定を設定するかを記述した README を作成することは、私の意見ではかなりうまく機能します。

継続的なビルドシステムがEclipse設定に加えられた変更を確実に理解できるようにする方法、それは別の問題です...（手作業で最新の状態に保つant用の別のbuild.xmlがあります）

于 2009-01-15T10:45:06.867 に答える