AntからMavenへの複雑なプロジェクトの移行-異常なフォルダー構造の処理方法
私の新しいプロジェクトでは、長年にわたって不快で制御されない方法で成長してきたいくつかのモジュールを備えた複雑なインフラストラクチャに直面しています。
要点：ビルドプロセスは恐怖です。 40を超える複雑なAntファイルが複数回接続され、SOAフレームワークはいくつかの動的Antファイルも生成します。すべての依存関係を本当に理解し、最終的にビルドするには数日かかりましたエラーなしでプロジェクト全体。
私の計画は、プロジェクト全体をAntからMavenに移行することでした。新しいコンポーネントが計画されており、将来はこれらの問題を回避したいと思っています。
私はより大きなプロジェクトの移行に慣れていないので、最高のワークフローについて少し混乱しています。多数のXMLファイルとスクリプトが関係しており、Maven以外のディレクトリ構造で配布されています。全体で3000を超えるファイルが関係しています。主な問題の1つは、既知のMavenディレクトリ構造内のすべてを移行しようとする必要があるかどうかわからないため、すべてのファイルを無限に編集およびリファクタリングするリスクがあることです。または、フォルダー構造をそのままにして、pom.xmlファイルを膨張させ、関連するすべてのプラグインで問題が発生する可能性がありますか？正直なところ、どちらの方法も非常に建設的ではありません。
この次元のプロジェクトをMavenに移行することも理にかなっていますか？特にSOAフレームワークが独自のAntファイルを使用する必要がある場合-したがって、AntとMavenの組み合わせが必要になります。このプロセスを簡素化する最適な戦略は何でしょうか？
すべての提案をありがとう。
AntプロジェクトのMavenizingに対する簡単で素早い答えを次に示します。
DO N'T DO IT！
これはいくつかの反Mavenスクリードではありません。私はMavenを使用しており、Mavenが好きです。開発者に愚かなことをしないように強制します。開発者はビルドスクリプトを書くのがひどいです。彼らは物事をこの方法で行いたいと思っています。 Mavenを使用すると、開発者は誰でも理解できる方法でプロジェクトをセットアップできます。
問題は、Mavenで完全にやり直さなければならないワイルドでクレイジーなことを、開発者がAntで行えることです。それは単なるディレクトリ構造ではありません。 Antは、複数のビルドアーティファクトを許可します。 Mavenでは、pom.xmlごとに1つしか使用できません1。 Antプロジェクトが半ダースの異なるjarファイルを生成し、それらのjarファイルに同じクラスの多くが含まれている場合はどうなりますか？ jarのためだけに半ダースのMavenプロジェクトを作成し、次にjar間で共通するファイルのためにさらに半ダースを作成する必要があります。
まさにこれをしたからです。システムアーキテクチャの責任者は、Mavenは新しくて良いものであり、Antは悪いものであり、悪いものでなければならないと判断しました。ビルドが機能し、適切に構造化されていても問題ありません。いいえ、Antは行かなければなりません。Mavenが道です。
開発者はこれをやりたくなかったので、私、CMに落ちました。 6か月かけてすべてをMavenに書き換えました。 WSLD、Hibernate、さまざまなフレームワークがあり、どうにかしてすべてを再構築してMavenで動作するようにしなければなりませんでした。私は新しいプロジェクトを生み出さなければなりませんでした。ディレクトリを移動する必要がありました。開発者が膨大な量の開発を行うのを止めることなく、物事を行う新しい方法を見つけなければなりませんでした。
これは地獄の最も内側の円でした。
Antプロジェクトが非常に複雑な理由の1つは、おそらく依存関係管理に関係しています。あなたが私たちの現在の店のようであれば、一部の開発者は 一緒にハックする develop独自の依存関係管理システム。この依存関係管理システムを見た後、開発者が絶対に記述してはならない2つのことを知っています。独自のビルドファイルと依存関係管理システムです。
幸いなことに、Antには Ivy と呼ばれる既存の依存関係管理システムがあります。 Ivyの良い点は、現在のMavenアーキテクチャで動作することです。サイトの集中Mavenリポジトリを使用でき、IvyはjarをMavenアーティファクトとしてそのリポジトリにデプロイできます。
開発者向けにすべてを自動的にセットアップするIvyプロジェクトを作成しました。必要なセットアップと構成、およびいくつかの標準Antタスクを置き換えることができるいくつかのマクロが含まれていました。 svn:externalsを使用して、このIvyプロジェクトをメインプロジェクトにアタッチしました。
現在のビルドシステムにプロジェクトを追加することはそれほど難しくありませんでした。
build.xmlプロジェクトを現在のプロジェクトに統合するには、ivy.dirに数行追加する必要がありました。- そのプロジェクトの
ivy.xmlファイルを定義する必要がありました。 <jarと</jar>のインスタンスを<jar.macroと</jar.macro>に変更しました。このマクロは、標準の<jar/>タスクが行うことをすべて行いましたが、Mavenビルドが行うようにpom.xmlもjarに埋め込みました。 （Ivyにはivy.xmlファイルをpom.xmlに変換するタスクがあります）。- 私は、他の開発者が追加した古い依存関係管理のがらくたをすべて削除しました。これにより、
build.xmlファイルを100行減らすことができます。また、チェックアウトとコミットを行ったもの、またはftpまたはscpしたものをすべて削除しました。これらはすべてJenkinsビルドシステム用でしたが、Jenkinsはビルドファイルの助けを借りずにこれを処理できます。ありがとうございます。 - 数行を追加して、Ivyを統合します。最も簡単な方法は、
libディレクトリ内のjarファイルを削除し、ivy.xml経由でダウンロードすることです。全体として、build.xmlでこれを行うには、数十行のコードを追加または変更する必要があります。
ビルドプロセス自体が混乱していなければ、数時間でIvyをプロジェクトに統合できるようになりました。 build.xmlをゼロから書き直さなければならなかった場合、2、3日かかるかもしれません。
Ivyを使用すると、Antビルドプロセスがクリーンアップされ、完全な再構築を行うことなくMavenで得られる多くの利点が得られました。
ちなみに、このプロセスに最も役立つツールは Beyond Compare です。これにより、新しいビルドプロセスが古いビルドプロセスと互換性があることをすばやく確認できました。
とにかくMavenに移動する...
おもしろいことに、AntプロジェクトをIvyと統合したら、それらをMavenプロジェクトに変えることはそれほど難しくありません。
build.xmlのロジックをクリーンアップします。最初から書き直さなければならないかもしれませんが、ほとんどの依存関係管理のガベージがなければ、それほど難しくありません。build.xmlがクリーンアップされたら、Mavenの構造に一致するまでディレクトリの移動を開始します。- 新しいディレクトリ構造に一致するようにソースを変更します。非標準の場所に* cssファイルを含むWARがあり、そのディレクトリにこれらのファイルを予期するようにコードが組み込まれています。新しいディレクトリ構造に一致するように、Javaコードを変更する必要がある場合があります。
- 複数のプロジェクトをビルドするAntプロジェクトを、それぞれが単一の成果物をビルドする個別のAntプロジェクトに分割します。
pom.xmlを追加し、build.xmlを削除します。
1 はい、これは完全に真実ではないことを知っています。サブプロジェクトとsuper pomsを持つMavenプロジェクトがあります。ただし、4つの異なる無関係なjarをビルドするMavenプロジェクトはありませんが、これはAntで非常に一般的です。
私は過去に同様の移行を行ってきましたが、あなたが持っていたのと同じ疑問を抱いていました。しかし、「フォルダ構造をそのままにして、POMファイルにパスを指定する」方法を選びましたが、思ったほど悪くないことに気付きました。
私が実際にやらなければならなかったことは、<sourceDirectory> そしてその <outputDirectory>そして、いくつかの包含および除外フィルターを追加するかもしれませんが、最終的には、Mavenの方法が本当に設定よりも慣習的であり、ファイルを配置する場所の指示に従うとあなたの生活が楽になりますが、本当にしないでくださいmuchしないと難しくなります。
それに、移行時に本当に助けになったのは、Mavenプロジェクトをモジュールに分割する可能性でした。最初はAnt構造を複製するために使用しました（つまり、build.xmlファイルごとに1つのMavenモジュールがありました）。より単純になり、モジュール集約を変更して、より意味のある、Mavenに似たものにしました。
これが実際にあなたにとって意味があるかどうかはわかりません。生成されたAntファイルがなかったので、それはあなたにとって最大の問題かもしれませんが、Mavenizeにファイルをリファクタリングして移動するのではなく、この道を間違いなく繰り返します私のプロジェクト構造。