150

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

これについて、ページ全体ではなく詳細な洞察を提供できる人はいますか?

これには、いわば多くのサブ質問が含まれており、Eclipse (およびワークスペース) のすべての側面を知っているわけではないと確信しているため、特定のサブ質問をすべて知っているわけではありませんが、私は'私が探しているものの例を挙げてみます：

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

私は、異なる言語とプロトコルを使用する開発者の最小のユースケースについて話しています。必ずしもすべてが 1 つのプロジェクトであるとは限りません(たとえば、一部のプロジェクトでは Php、Javascript と XML、他のプロジェクトでは C#、さらに他のプロジェクトでは Java と SQL など)。 ..)

編集 2012-11-27: 誤解しないでください。ワークスペースの使用に疑いはありません。意図したとおりに使用したいだけです。それで「何のために？」意味：一番の使い道は？なぜ？" 言い換えれば、あなたの答えの理由を教えてください。

4

5 に答える 5

47

Java の世界で非常に居心地が悪いと感じている人のビジョンを紹介しますが、それはあなたも同じだと思います。

それは何ですか

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

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

これは、ディレクトリを作成し、その中にファイルを配置することによって行われます (それを行う必要はありません。自動的に行われます)。Eclipse にこれらの情報を伝えることができます。明示的に行う必要があるのは、これらのファイルが配置されるフォルダーを選択することだけです。また、このフォルダーは、ソース コードを配置した場所と同じである必要はありません。そうでないことが優先されます。

上記の各項目を調べる:

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

Eclipse は常に特定のワークスペースに関連して開かれているようです。つまり、ワークスペース A にいて、ワークスペース Bに切り替えることにした場合([ファイル] > [ワークスペースの切り替え])、Eclipse は自動的に閉じて再度開きます。ワークスペース Aに関連付けられていた(そして Project Explorer に表示されていた) すべてのプロジェクトは表示されなくなり、ワークスペース Bに関連付けられたプロジェクトが表示されるようになります。そのため、プロジェクトを Eclipse で開くには、ワークスペースに関連付ける必要があるようです。

これは、プロジェクトのソース コードがワークスペース内にある必要があるという意味ではないことに注意してください。ワークスペースは、どういうわけか、ディスク内のプロジェクトの物理パスと関係があります (誰もがその方法を知っていますか?ワークスペース内を調べて、プロジェクトのパスを指すファイルを探しましたが、成功しませんでした)。

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

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

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

  1. 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

于 2014-12-23T20:47:24.140 に答える
38

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

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

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

于 2012-11-26T04:32:19.957 に答える
3

Basically the scope of workspace(s) is divided in two points.

First point (and primary) is the eclipse it self and is related with the settings and metadata configurations (plugin ctr). Each time you create a project, eclipse collects all the configurations and stores them on that workspace and if somehow in the same workspace a conflicting project is present you might loose some functionality or even stability of eclipse it self.

And second (secondary) the point of development strategy one can adopt. Once the primary scope is met (and mastered) and there's need for further adjustments regarding project relations (as libraries, perspectives ctr) then initiate separate workspace(s) could be appropriate based on development habits or possible language/frameworks "behaviors". DLTK for examples is a beast that should be contained in a separate cage. Lots of complains at forums for it stopped working (properly or not at all) and suggested solution was to clean the settings of the equivalent plugin from the current workspace.

Personally, I found myself lean more to language distinction when it comes to separate workspaces which is relevant to known issues that comes with the current state of the plugins are used. Preferably I keep them in the minimum numbers as this is leads to less frustration when the projects are become... plenty and version control is not the only version you keep your projects. Finally, loading speed and performance is an issue that might come up if lots of (unnecessary) plugins are loaded due to presents of irrelevant projects. Bottom line; there is no one solution to every one, no master blue print that solves the issue. It's something that grows with experience, Less is more though!

于 2013-12-31T17:03:22.213 に答える