7

プログラマーのチームが同じプロジェクトで Netbeans、Eclipse、および IntelliJ を使用できるようにする最善の方法は何ですか?

ソース コード管理にチェックインする必要があるファイルとチェックインしないファイルはどれですか?

4

9 に答える 9

10

ビルドプロセスをIDEから独立させるのが最善の方法だと思います。つまり、プロジェクトはIDE固有のファイルに依存してビルドするのではなく、Apache Maven、Apache Ant、さらにはmakeまたはcustomスクリプトなどの外部ビルドシステムを使用する必要があります。Mavenは、直接またはプラグインを介して、最も一般的なJavaIDEでサポートされています。

外部ビルドシステムを使用したくない場合は、少なくともプロジェクトをできるだけ簡単にセットアップできるようにする必要があります（つまり、共有ライブラリやその他の依存関係用の標準フォルダーを用意する必要があります）。過去に複数のIDEを使用するチームで作業していたとき、プロジェクトを構築するための前提条件が時間の経過とともに変化したため、依存関係の解決に最も多くの時間を費やしました。最悪の場合、開発者は新しいプロジェクトの設定が非常に面倒だと考えているため、バージョン管理リポジトリから最新バージョンを取得する必要がなくなる可能性があります。

プロジェクトに多くのライブラリ依存関係がある場合は、バージョン管理リポジトリでこれらをバイナリ形式で利用できるようにすることをお勧めします。そうすれば、単一のプロジェクトを構築するためだけに、依存関係などのすべての依存関係を解決する必要がなくなります。ただし、これには、「公式」バイナリが変更されるたびに最新の状態に保つ責任がある人が必要です。（これは、Mavenリポジトリーで使用される哲学とほぼ同じですが、Mavenを使用しない場合でも、原則を手動で適用できます。）

于 2008-10-16T13:31:07.547 に答える
6

まあ、それはかなり自問自答の質問です。

ソース管理にチェックインしないファイルは、IDE 自体に関係するファイルです。

これらのファイルの生成は開発者に任せてください。

.projectMaven を使用すると、Eclipse などのファイル.classpathを自動的に生成できます。Java Project一般に、Eclipse は基本的なファイル構造 (新しいオプションを使用) で非常に使いやすいです。

MavenもNetbeansをサポートしていると思いますが、IntelliJについてはわかりません。

Maven のサイトはmaven.apache.orgです。

于 2008-10-16T02:35:59.257 に答える
5

複数の開発者がいる IDE ごとに、すべてのサポート ファイルをチェックインします。すべてのデスクで車輪を再発明する理由。

私は多くの異なる IDE でこれを行いましたが、ファイル名の競合はまだ見たことがありません。

実際、特定の IDE を使用する開発者が 1 人だけの場合でも、開発環境で他のファイル (履歴、差分、コメントなど) をバージョン管理するのと同じ理由で、サポート ファイルをバージョン管理することは開発者にとって有利です。

于 2008-10-16T02:50:22.070 に答える
4

Eclipse の場合、それは .classpath および .project ファイルになります。

私のチームは Maven を使用しており、開発者は Eclipse 固有のファイルをチェックインすることをお勧めしません。これらは Maven から生成できるため、これらのファイルは冗長です。

また、プロジェクト固有のファイルをチェックすると時間を節約できるように思えますが、開発者のワークステーションが異なるため、IDE 固有のファイルの競合を解決するのに時間がかかるため、通常は面倒です。これを回避する唯一の方法は、全員に同じ方法で環境をセットアップするよう強制することです。これは、IDE に依存しないアプローチに反します。

于 2008-10-16T03:36:21.897 に答える
3

同じプロジェクト チーム内で複数のツールセットを使用する場合、多くの考慮事項があります。たとえば、私のチームには、IntelliJ を使用する Java 開発者と、Eclipse を使用するほとんどのフロントエンド (JSP/CSS/HTML) 開発者がいます。Eclipse ユーザーを IntelliJ に移行する過程にあるのは、開発した一部の IntelliJ プラグインが環境の拡張サポートを提供するためです。複数のプラットフォーム用のプラグインを開発するつもりはないので、全面的に IntelliJ で標準化しています。

特定のファイルに関しては、IntelliJ と話すことができます。.ipr ファイルと .iml ファイルをチェックインしました。.iws ファイルをチェックインしないでください。Eclipse ユーザーもいる場合は、IntelliJ プロジェクトを構成して、.classpath ファイルの依存関係情報を読み取り/保存し、それを VCS にコミットします。

于 2008-10-16T02:40:59.780 に答える
1

このトピックに関するその他のコメントと回答については、この質問を参照してください (How do you handle different Java IDEs and svn?)

于 2008-12-23T10:51:28.337 に答える
1

同じ SVN リポジトリからの複数の IDE を意図的にサポートしています。新しい人がチームに参加したり、誰かが新しいマシンで作業を開始したりした場合、コードベースをチェックアウトして IDE にインポートし、すぐに作業できるようにしたいと考えていました。可能な構成。

これが開発者にとって意味することは、変更を IDE ファイルにコミットしてはならないということです。他のすべて (たとえば、src、test、lib など) は、通常、毎日更新およびコミットするセットになります。

副次的な利点は、ここで IDE 戦争を完全に排除したことです。Netbeans と Eclipse の人々は完全に調和して暮らしています (IntelliJ の人々に目を向けると、ちょっと... ;-)。

于 2008-10-16T13:19:41.830 に答える
0

チェックイン用の IDE ファイルの名前を、追加の拡張子 .deletethis などで変更します。新しい人がプロジェクトをチェックアウトすると、余分な拡張機能を取り除くだけで準備完了です。このようにして、人々が環境を微調整するときに、プロジェクト ファイルとのソース管理の競合を回避します。また、これらのファイルをチェックインしないように新しい開発者を教育することについて心配する必要もありません。

于 2008-12-23T07:50:56.827 に答える
-1

通常、これは悪い考えだと思います。これがどのような環境であるか（おそらくオープンソース？）はわかりませんが、複数のIDEをサポートするのは本当に大変です。これが避けられない場合に私がお勧めすることの1つは、antスクリプトでビルドを標準化することです。依存関係のセットが大きい場合、これはすべてのプラットフォームで予測可能なビルドを取得するための最も簡単な方法である可能性があります。

IDEの1つがたまたまRAD（Eclipseに基づく）である場合、SCMに含めたくない.settingsというフォルダー全体があります。

于 2008-10-16T06:15:15.650 に答える