1

アプリケーションの Ant ビルド ファイルには次の階層があります。

Application
|---MainProject
|       |__ build.xml
|
|---Project1
|       |__ build.xml
|
|---Project2
       |__ build.xml

タスクに基づく Ant ターゲットは、次のように配布されます。

1) MainProject ビルド ファイルは、他のすべてのビルド ファイルのターゲットをant呼び出します。clean

2) すべてのプロジェクトの JUnit テストは、内部に junit タスクを含む共通の junit ターゲットを使用して MainProject ビルド ファイルで実行されます。

3) 他のビルド ファイル内の他のすべてのタスクは、他のすべてのファイル内のターゲットantへの呼び出しを通じて実行されます。build-project

4) build-project ターゲットは、個々のファイルで実行するタスクをさらに決定します。

このアーキテクチャはどのように見えますか? そのようなシナリオに対するあなたのアプローチは何ですか? それについての推奨される方法は何ですか？

4

1 に答える 1

1

これは、ANT におけるかなり典型的なマルチモジュール ビルド シナリオであり、時間が経つにつれて、かなり典型的な大規模なモノリシック プロジェクト ビルドにつながります....

私が提案したいのは、Mavenがマルチモジュールプロジェクトをどのように構造化するかを検討することです。各モジュールがビルドされたアーティファクトをプッシュする場所である "ローカル リポジトリ" の Maven の概念をシミュレートしたいとします。クラスパスを共有しないでください。代わりに、各「build.xml」ファイルがローカル リポジトリのファイルに基づいてクラスパスを作成します。

<path id="compile.path">
    <fileset dir="${local.repo.containing.built.jars}" includes="*.jar"/>
    <fileset dir="${dir.containing.third.party.jars}" includes="*.jar"/>
</path>

メリット

  • 各サブモジュールは、プロジェクト全体の完全な再構築を強制することなく、(開発中に) スタンドアロンの方法で構築できます。
  • サードパーティの依存関係は、クラスパス内で明確に区別されています

プロジェクトが成長するにつれて、モジュール間の相互依存性を意識する必要があります。サブモジュールの数が少ない場合、ビルド順序は明らかですが、時間が経つにつれて、サブモジュールは、最初にビルドされる他の多くのサブモジュールに依存するようになる場合があります。

最後に、apache ivyプロジェクトは、Maven のような機能を ANT ビルドに追加するためのツールを提供します。マルチモジュールの例がありますが、初心者にはわかりにくいと思いました。私はそれをあなたのバックログに入れ、サブモジュール アーティファクトを将来的に Nexus のような Maven リポジトリに公開することを検討します。これにより、Ant ビルドは、Maven や Gradle などの代替ビルド テクノロジを使用する他のチームと互換性を持つようになります。

アップデート

于 2013-01-10T22:23:14.393 に答える