17

私はかなり大きな (いくつかの MLOC) アプリケーションを手元に持っており、それをより保守しやすい別々の部分に分割したいと考えています。現在、この製品は約 40 の Eclipse プロジェクトで構成されており、その多くは相互に依存しています。これだけでは、チェックインごとに非常に多くの再構築が必要になるため、継続的なビルド システムは実行不可能になります。

「ベストプラクティス」の方法はありますか

  • すぐに分離できる部分を特定する
  • 相互依存関係を視覚的に文書化する
  • 既存のコードを解く
  • ライブラリに適用する必要がある「パッチ」を処理します（現在、実際のライブラリの前にクラスパスに配置することで処理されます）

これをサポートする (無料/オープンな) ツールがある場合は、ポインタをいただければ幸いです。

私は Maven の経験がありませんが、非常にモジュール化された設計を強制しているようです。これが反復的に後付けできるものなのか、それともそれを使用するプロジェクトは最初からモジュール性を念頭に置いてレイアウトする必要があるのか​​ 疑問に思っています.

2009-07-10 を編集

Apache Ant/Ivyを使用していくつかのコア モジュールを分割しています。本当に便利でよく設計されたツールであり、maven ほどあなたに課すことはありません。

なぜ私たちがそれを行っているのかについて、より一般的な詳細と個人的な意見をブログに書き留めました。

4

7 に答える 7

9

OSGiの使用は、あなたにぴったりかもしれません。アプリケーションからモジュールを作成することができます。より良い方法で依存関係を整理することもできます。異なるモジュール間のインターフェイスを正しく定義すると、チェックイン時に影響を受けたモジュールを再構築するだけでよいため、継続的インテグレーションを使用できます。

OSGi が提供するメカニズムは、既存のコードを解きほぐすのに役立ちます。クラスローディングの仕組みにより、パッチを簡単に処理することもできます。

ウィキペディアから示されているように、あなたにぴったりだと思われるOSGiのいくつかの概念:

このフレームワークは、概念的に次の領域に分けられます。

  • バンドル - バンドルは、追加のマニフェスト ヘッダーを持つ通常の jar コンポーネントです。
  • サービス - サービス レイヤーは、Plain Old Java Objects (POJO) の公開-検索-バインド モデルを提供することにより、動的な方法でバンドルを接続します。
  • サービス レジストリ - 管理サービス (ServiceRegistration、ServiceTracker、および ServiceReference) の API。
  • Life-Cycle - ライフサイクル管理 (バンドルのインストール、開始、停止、更新、およびアンインストール) 用の API。
  • モジュール - 依存関係のカプセル化と宣言 (バンドルがコードをインポートおよびエクスポートする方法) を定義するレイヤー。
  • セキュリティ - バンドル機能を事前定義された機能に制限することにより、セキュリティの側面を処理するレイヤー。
于 2009-05-19T07:35:18.967 に答える
6

1つ目：幸運とおいしいコーヒー。両方が必要になります。

私はかつて同様の問題を抱えていました。org.example.pkg1.A のような異なるパッケージのクラス間であっても、ひどい循環依存関係を持つレガシー コードは org.example.pk2.B に依存し、その逆も同様です。

私はmaven2と新鮮なEclipseプロジェクトから始めました。最初に、最も一般的な機能 (ロギング レイヤー、一般的なインターフェイス、一般的なサービス) を特定し、Maven プロジェクトを作成しました。パーツに満足するたびに、ライブラリを中央の nexus リポジトリにデプロイして、他のプロジェクトですぐに利用できるようにしました。

それで、私はゆっくりとレイヤーを重ねました。maven2 は依存関係を処理し、m2eclipse プラグインは便利な依存関係ビューを提供しました。ところで - 通常、Eclipse プロジェクトを Maven プロジェクトに変換することはそれほど難しくありません。m2eclipse を使用すると、いくつかの新しいフォルダー (src/main/java など) を作成し、ソース フォルダーのビルド パスを調整するだけで済みます。所要時間は 1 ～ 2 分です。ただし、プロジェクトが Eclipse プラグインまたは rcp アプリケーションであり、アーティファクトを管理するだけでなく、アプリケーションをビルドおよびデプロイするために Maven が必要な場合は、さらに困難が予想されます。

意見としては、eclipse、maven、および nexus (またはその他の Maven リポジトリ マネージャー) が出発点として適しています。システム アーキテクチャの優れたドキュメントがあり、このアーキテクチャが実際に実装されている場合は、幸運です;)

于 2009-05-19T07:38:53.297 に答える
3

小さなコードベース（40 kloc）でも同様の経験をしました。°ルールはありません」：

  • 使用法を確認するために、「モジュール」がある場合とない場合でコンパイルされます
  • 私は「リーフモジュール」、他の依存関係のないモジュールから始めました
  • 循環依存を処理しました（これは非常にエラーが発生しやすいタスクです）
  • Mavenを使用すると、CIプロセスにデプロイできるドキュメント（レポート）が大量にあります
  • Mavenを使用すると、サイトとNetBeansの両方で何が使用されているかを常に確認できます（
    非常に優れた有向グラフを使用）
  • Mavenを使用すると、コードベースにライブラリコードをインポートし、ソースパッチを適用して、製品でコンパイルできます（これは非常に簡単な場合もあれば、非常に難しい場合もあります）

依存関係アナライザーも確認 してください:(ソース：javalobby.org）

Netbeans：


（ソース：zimmer428.net）

于 2009-05-19T07:58:44.370 に答える
1

Maven を既存のシステムに移行するのは面倒です。ただし、100 以上のモジュール プロジェクトを問題なく処理できます。

于 2009-05-19T19:16:40.690 に答える
0

従来のソース コード ベースには Maven をお勧めしません。すべてを適応させようとするだけで、多くの頭痛の種になる可能性があります。

必要なのは、プロジェクトのアーキテクチャ レイアウトを行うことだと思います。ツールが役立つ場合もありますが、最も重要な部分は、モジュールの論理ビューを整理することです。

于 2009-05-19T07:35:15.893 に答える