大量のMavenアーティファクトで構成されるかなり大きなJavaアプリケーションがあります。各サブシステムは、サブバージョンツリーにtrunk /、branchs /、tags /サブフォルダーを含む独自のフォルダーを持ち、複数のアーティファクトをホストします。MavenPOMの階層には複数のレベルがあります。依存関係管理でさえ、異なるモジュールに分割されます。アプリケーションは、複数のWARおよびその他のZip/JARのものとしてデプロイされます。
それを構築してデプロイする過程で、私はしばしばアプリケーションを1つのユニットとして見なければなりません。そして、私はここで共有したいたくさんの困難に遭遇しました。
Subversionレイアウト：1つのコマンドでコードベース全体をチェックアウトすることはできないという事実から始まります。トップレベルから始めて、すべてのサブプロジェクトからすべてのブランチをチェックアウトすると、単純に大きすぎて時間がかかりすぎます。アーティファクトの数を減らすことは、根本的な変更が多すぎるため、現在のところ実際にはオプションではないと思います。しかし、集約されたブランチフォルダを使用した別のSubversionレイアウトが実際に役立つ可能性があります。私が試した回避策の1つは、適切なサブフォルダーをまとめた、多数のSubversion外部を含む別のフォルダーを作成することです。次に、たとえば、トップレベルのマルチモジュールアーティファクトから1つのmavenコマンドを使用してすべてをビルドできます。
リリース：リリースはコードベース全体で行われます。最初に、プロジェクト用に特別に作成されたカスタムツールを使用する巨大な依存関係グラフを作成します。これは、Mavenで直接行うことはできないためです。次に、依存関係ツリーのアーティファクトの1つのレイヤーを段階的にリリースする必要があります。最初に、依存関係のないアーティファクトを作成し、親POMを新しいバージョンにうまく適合させた場合は、それらをビルドして、次のレイヤーに進みます。 。時々、すべてのバージョン管理作業を2回、1回はSubversionで、もう1回はすべてのPOMで実行したいと思うことがあります。リリースプラグインは、依存関係管理を自動的に適応させることもできないようです。
ハドソン：ハドソンでは、すべての親アーティファクトに対して20のジョブがあります。また、アーティファクトごとに3つのアクティブなブランチがあります。これは60の仕事のようになります。ブランチが変更されるたびに、ブラウザで多くのマウスクリックが発生します。少なくとも、依存ジョブの自動ビルドトリガーは機能しています。ただし、モジュールがコンパイルジョブとレポートジョブに分割されている場合は、これも問題を引き起こします。通常、コンパイルはレポートの生成よりもはるかに頻繁に行われ、後者は前者の速度を低下させるべきではありません。ただし、レポートジョブが実行されるたびに、すべてのコンパイルジョブもトリガーされます。アーティファクトが実際にデプロイされている場合、ハドソンは依存ジョブのみをトリガーできないようです。また、プロジェクト全体に対して1つの巨大なマルチモジュールビルドを作成しようとしましたが、インクリメンタルビルド機能が正しく機能しません。そして、それがないと、ビルドに時間がかかりすぎます。ただし、依存するアーティファクトを構築する必要があります。これは、1つのアーティファクトがどのような変更を引き起こすかを確信できないためです。
集計レポート：親POMの各レベルについて、単体テスト、テストカバレッジ、チェックスタイルなどの集計レポートを生成する方法をまだ理解していませんでした。一部のプラグインは、集約オプションをサポートしていません。他の人のために、私は階層の各レベルに対して再度ビルドを行わなければなりません。Mavenサイトのレポートは問題ありませんが、かなり静的であり、閲覧時に使用できるのは限られているようです。おそらく、ここでのより良いオプションは、SonarSourceやその他のソースコード分析ツールのようなものを使用することです。また、これらのレポートをハドソンに統合することは私には理想的ではないようです。
私の観点からは、1つのディレクトリをチェックアウトし、ソースからすべてを構築し、リリース用に1つのタグ/バージョンを作成し、外部リポジトリに依存せず、Hudsonで1つのジョブを構成できる大きなリポジトリを1つだけ作成したいと思います。しかし、これはおそらく、さまざまな開発者チームが必要としているものとはかけ離れています。どういうわけか、両方の管理可能な方法を見つけるのは難しいようです。