4

現在の製品は Eclipse RCP に基づいています。コードベース全体を 1 つの Eclipse ワークスペース内に配置しようとすると問題が発生し始め、他の人が何をしているのか疑問に思っていました。

セットアップは次のとおりです。

  1. ~225 の eclipse プロジェクト (すべてトランク/プロジェクト内)
  2. ~30 の eclipse 機能 (すべてトランク/機能内)
  3. 約 90 万行のコード

いくつかの異なるボトルネックが見つかりました。

  1. Windows 上の SVN は非常に遅く (TortoiseSVN、SmartSVN、コマンド ライン svn を試しました)、更新に 5 ～ 8 分以上かかることがあり、10 個の小さなファイルしか更新していません。妥当な唯一のクライアントは subclipse/subversive ですが、これらには他の問題があり、いくつかの問題がありました。
  2. Eclipse の更新には 3 ～ 5 分かかる場合があります
  3. Eclipse のビルドには 5 ～ 15 分かかる場合があります

この解決策は、1 人の開発者がいつでもチェックアウトしてアクティブにする必要があるプロジェクトの量を制限していると私は信じています。

たとえば、最初に考えたのは、ターゲット プラットフォームをトランクからの最後の「安全な」ビルドに設定し、その上にあるプロジェクトをチェックアウトすることです。これは機能しますが、効果的にオーバーライドしたプロジェクトに依存するプロジェクトが壊れているかどうかはわかりません。

もう 1 つの考えは、プロジェクト セットを使用して、その方法で必要なものだけをチェックアウトすることでした。

他の誰かがこの問題に遭遇しましたか? もしそうなら、あなたはそれを回避するために何をしていますか?

ありがとう。

4

1 に答える 1

2

この種の構成に採用したポリシーは、展開の概念を中心としたものです。

どのプロジェクトも、配信される一連のファイル (jar、war、ear など) をビルドしてからバージョン管理する責任があります。

つまり、次のことを意味します。

  • すべてのシステムのテストを担当する「統合チーム」は、すべての配信を再構築することなく、VCS への 1 回の要求ですべての配信をすばやく更新できます。したがって、「展開」という言葉は、このアプローチによって促進されます。

  • あなたの質問にとってさらに重要なことは、プロジェクトは、動作してコードの進化を行うためにコンパイルする必要がある配信をクエリするだけでよいということです。

したがって、任意のプロジェクトについて、実際に Eclipse で開かれるのは 1 つだけであり、他のプロジェクトからのさまざまなライブラリを参照します。

これにより、次のことも余儀なくされました。

  • すべてのプロジェクト間のさまざまな依存関係を再考します (削除する循環依存関係のいくつかのケースを検出します)。
  • いくつかのプロジェクトが「粒度が細かすぎる」ため、まとめてまとめる必要があることに気付いたとき、アプリケーション アーキテクチャを再確認してください。

基本的に 2 つのアプローチがあります。

  • すべてのアプリケーションのすべての部分を一緒に開発でき、必要なすべてのプロジェクトにソースの依存関係があるシステムベース。
  • コンポーネント ベース。プロジェクトにはソース依存関係がなく、ライブラリのみに依存します。

eclipse-plugin アプローチでは、妥協点を見つける必要があります。
同じドメイン (" com.mycorp.fileutil[.XXX]" など) からのすべてのプロジェクトは、それらの間のソース依存関係を持つ Eclipse プロジェクトによって表すことができます。しかし、そのドメインの一部ではない " " が必要とするその他のコンポーネントcom.mycorp.fileutilは、ソースの依存関係としてではなく、ライブラリとしてインポートする必要があります。したがって、私たちの「展開中心、リリース ファースト」の視点です。

于 2009-05-15T23:13:14.800 に答える