ワークスペースのさまざまな使用方法（プロジェクトごと、アプリケーションごと（マルチアセンブリかどうか）、プログラム言語ごと、ターゲットごと（Web開発、プラグインなど）など）を見て、読んだり、考えたりしたことがあります。まだ最善のアプローチが何であるか疑問です。

とにかくこれについての詳細な洞察をページに与えることはできませんか？

これには、いわば多くのサブ質問が含まれます。私が尋ねるべき具体的なサブ質問がすべてわからないので、Eclipse（およびワークスペース）のすべての側面がわからないので、私が探しているものの例を挙げましょう：

• 何のために？
  
  • 食の開発はそれが使用されることをどのように意味しましたか？
  • 他の/ほとんどの人はどう思いますか？
  • どう思いますか？
  • ...？
• どうして？
  
  • 構成の競合と共有のメリットはありますか？
  • ファイルスペースの理由はありますか？
  • パフォーマンス？
  • ...？

ああ、私は異なる言語とプロトコルを使用する開発者の最小限のユースケースについて話しており、必ずしもすべてが1つのプロジェクトですべてではない（例：一部のプロジェクトではphp、javascriptおよびxml、他のプロジェクトではC＃、まだJavaおよびSQL）その他など）

編集2012-11-27：誤解しないでください。私はワークスペースの使用を疑うのではなく、それが意図されているように、または誰かがそれをより良く考えると思われる場合は、それを使用したいだけです。それで「何のため？」意味：最適な用途は何ですか？なぜ？" 実際には「何のために？」をターゲットにしています。つまり、答えの理由を教えてください。

私は、Javaの世界で非常に不快に感じる誰かの私のビジョンを提供します。

それはなんですか

ワークスペースは、グループ化の概念です。

1. （どういうわけか）関連するプロジェクトのセット
2. これらすべてのプロジェクトに関連するいくつかの構成
3. Eclipse自体の設定

これは、Eclipseにこれらの情報を通知するために管理するディレクトリを作成し、その中にファイルを配置することによって行われます（実行する必要はありません。実行されます）。明示的に行う必要があるのは、これらのファイルを配置するフォルダーを選択することだけです。そして、このフォルダーは、ソースコードを配置した場所と同じである必要はありません。

上記の各項目について：

1. （どういうわけか）関連するプロジェクトのセット

Eclipseは常に特定のワークスペースに関連して開かれているようです。つまり、ワークスペースAでワークスペースBに切り替える場合（[ファイル]> [ワークスペースの切り替え]）、Eclipseは閉じて再び開きます。ワークスペースAに関連付けられていた（そしてプロジェクトエクスプローラーに表示されていた）すべてのプロジェクトは表示されなくなり、ワークスペースBに関連付けられたプロジェクトが表示されます。したがって、Eclipseで開くプロジェクトは、はワークスペースに関連付けられている必要があります。

これは、プロジェクトのソースコードがワークスペース内になければならないという意味ではないことに注意してください。ワークスペースは、どういうわけか、ディスク内のプロジェクトの物理パスと関係があります（誰もが知っていますか？ワークスペース内を調べて、プロジェクトパスを指すファイルを検索しましたが、成功しませんでした）。

このようにして、プロジェクトは一度に複数のワークスペース内に存在できます。したがって、ワークスペースとソースコードを分離しておくのが良いようです。

2. これらすべてのプロジェクトに関連するいくつかの構成

Javaコンパイラーのバージョン（1.7など）のようなものは、「バージョン」がここにあるかどうかはわかりませんが、ワークスペースレベルの構成であると聞きました。ワークスペース内に複数のプロジェクトがあり、それらをEclipse内でコンパイルする場合、それらすべてが同じJavaコンパイラーでコンパイルされます。

3. Eclipse自体の設定

キーバインディングのようなものも、ワークスペースレベルで保存されます。したがって、ctrl + tabでタブを切り替える（スタックしない）ように定義した場合、これは現在のワークスペースにのみバインドされます。別のワークスペースで同じキーバインディングを使用したい場合（そして私はあなたが望んでいると思います！）、それらをワークスペース間でエクスポート/インポートする必要があるようです（そうである場合、このIDEは非常に奇妙な前提の上に構築されました）。こちらがこのリンクです。

また、ワークスペースは異なるEclipseバージョン間で必ずしも互換性があるとは限りません。 この記事では、Eclipseバージョンの名前を含むワークスペースに名前を付けることをお勧めします。

さらに重要なのは、ワークスペースにするフォルダーを選択したら、その中のファイルに触れないでください。問題が発生することがあります。

私がそれを使う良い方法だと思う方法

（実際、これを書いているので、これを上手に使用する方法がわかりません。それが私が答えを探していた理由です-私はここで組み立てようとしています）

1. プロジェクト用のフォルダーを作成します。
   /projects

2. プロジェクトごとにフォルダを作成し、その中にプロジェクトのサブプロジェクトをグループ化します。
   /projects/proj1/subproj1_1
/projects/proj1/subproj1_2
/projects/proj2/subproj2_1

3. ワークスペース用に別のフォルダーを作成します。
   /eclipse-workspaces

4. プロジェクトのワークスペースを作成します。
   /eclipse-workspaces/proj1
/eclipse-workspaces/proj2

ワークスペースの要点は、通常はアプリケーションを構成する一連の関連プロジェクトをグループ化することです。ワークスペースフレームワークはeclipse.core.resourcesプラグインに属し、設計上当然のことながら理にかなっています。

プロジェクトには性質があり、ビルダーは特定のプロジェクトに関連付けられています。1つのプロジェクトでリソースを変更すると、同じワークスペースにあるプロジェクトのコンパイルまたはその他の問題をリアルタイムで確認できます。したがって、私が提案する戦略は、作業するプロジェクトごとに異なるワークスペースを用意することですが、Eclipseのワークスペースがないと、プロジェクトと構成のコレクションという概念はなく、結局それはIDEツールです。

それが意味をなさない場合、Net BeansまたはVisual Studioがこれにどのように対処するかを尋ねますか？同じテーマです。Mavenは良い例です。関連するMavenプロジェクトのグループをワークスペースにチェックアウトすると、エラーをリアルタイムで開発して確認できます。ワークスペースでない場合、他に何を提案しますか？RCPアプリケーションは、その用途に応じて異なる獣になる可能性がありますが、本当のIDEの意味では、ワークスペースやプロジェクトのコンテキストよりも優れたソリューションは何なのかわかりません。ただ私の考え。-ダンカン

基本的に、ワークスペースのスコープは2つのポイントに分けられます。

最初のポイント（およびプライマリ）は、それ自体が日食であり、設定とメタデータ構成（プラグインctr）に関連しています。プロジェクトを作成するたびに、eclipseはすべての構成を収集し、それらをそのワークスペースに保存します。同じワークスペースに何らかの方法で競合するプロジェクトが存在する場合、機能の一部が失われたり、Eclipse自体の安定性が失われたりする可能性があります。

そして、2番目（二次）に採用できる開発戦略のポイント。プライマリスコープが満たされ（そしてマスターされ）、プロジェクト関係（ライブラリ、パースペクティブctrなど）に関するさらなる調整が必要になると、個別のワークスペースを開始することが、開発の習慣または可能な言語/フレームワークの「動作」に基づいて適切になる場合があります。たとえば、DLTKは別のケージに入れられるべき獣です。フォーラムで多くの不満が機能しなくなったため（適切かどうかにかかわらず）、推奨される解決策は、現在のワークスペースから同等のプラグインの設定を削除することでした。

個人的には、使用されているプラ​​グインの現在の状態に伴う既知の問題に関連する個別のワークスペースに関しては、言語の区別に傾いていることに気付きました。できれば、プロジェクトを最小化することで、プロジェクトへの不満が少なくなります。プロジェクトを維持するバージョンはバージョン管理だけではありません。最後に、ロードの速度とパフォーマンスは、無関係なプロジェクトが存在するために多数の（不要な）プラグインがロードされた場合に発生する可能性がある問題です。結論; すべての人に1つの解決策はなく、問題を解決するマスターブループリントはありません。それは経験とともに成長するものですが、Lessはより多くです！

私は長年Eclipseを使用してきましたが、この "答え"は推測に過ぎません（今夜試してみたいと思います）。それが存在しないとして反対投票された場合、明らかに私は間違っています。

Oracleは、CMakeを使用して、MySQL Connector Cソースコード用のVisual Studio「ソリューション」を生成します。ソリューション内には、個別にまたはまとめて（ソリューションによって）コンパイルできる「プロジェクト」があります。各プロジェクトには独自のメイクファイルがあり、ソリューションの一部を他のプロジェクトとは異なる設定でコンパイルします。

同様に、Eclipseワークスペースが関連するメイクファイルプロジェクト（Eclipse）を保持できることを願っています。マスタープロジェクトは、その依存関係がさまざまな一意のメイクファイルプロジェクトをコンパイルして、その「ソリューション」を構築するための事前必要条件としてコンパイルします。（私のフォルダー構造は@Rafaelが説明するとおりです）。

したがって、ワークスペースを使用する良い方法は、異なるプロジェクトをソリューションに結合するVisual Studioの機能をエミュレートすることです。