ソースコードに依存するすべてのサードパーティJARを、ソースコードとともにソース管理にチェックインします。必要に応じて、サードパーティのJARの更新を手動でダウンロードし、ソース管理されているJARを新しいバージョンに置き換えます。このプロセスは私たちにとって十分に単純であるように思われるため、Mavenを使用する必要性はまだ感じていません。しかし、Mavenを使用しないことで、大きな価値のあるものが欠けているのでしょうか。または、私たちのシナリオはMavenの使用を保証しませんか?
3 に答える
「JARはあまり変わらない」、私はいつもこれを聞きます.....
SCMへのjarの保存は、プロジェクトの開始時に簡単です。時間の経過とともに、jarの数はどんどん増えていきます。2、3年待つと、jarがどこから来たのか、ライセンス条件は何か、最も一般的にはどのバージョンが使用されているのかを誰も覚えていません(セキュリティの脆弱性を分析するときに知っておくことが重要です)。 ....。
私が最近読んだ中で、リポジトリマネージャを主張する最高の記事は次のとおりです。
少し不遜ですが、常に遭遇する技術的な慣性の種類については有効なポイントになります。
プロジェクトチームをANTからMavenに切り替えるのは恐ろしいことです。Mavenの動作はまったく異なるため、グリーンフィールドまたは冒険的なプロジェクトチームで展開するのが最適だと思います。古い学校のANTユーザーには、Apacheivyプラグインを使用することをお勧めします。Ivyを使用すると、そのようなチームは依存関係の管理を外部委託できますが、快適なビルドテクノロジーを維持できます。
最終的に、Mavenを使用する最大の利点は、依存関係の管理ではありません。これは、標準化されたビルドプロセスです。「標準」のANTビルドプロセスを作成する試みが何度か失敗したのを見てきました。問題すべてのビルドエンジニアは、標準がどうあるべきかについて意見を持っています。ユーザーにビルドプラグインの作成を強制するというMavenのアプローチは、最初は制限があるように見えるかもしれませんが、iPhoneのように、最終的に開発者は「そのためのMavenプラグインがある」ことを発見します。 -)
依存関係の管理に関しては、Mavenは非常に価値があります。Mark O'Connorが示唆しているように、ローカルリポジトリマネージャーを実行する方が、アーティファクトをソース管理にチェックインするよりも優れている可能性があります。
依存関係の管理に役立ち、どのモジュールまたは依存関係が他のどの依存関係を必要とするかについての貴重なフィードバックを提供できる多くのツール(eclipseのm2eなど)があります。Mavenは、異なるモジュールが特定のライブラリの異なるバージョンに依存している場合でも、適切なバージョンの依存関係を確実に取得します。これにより、同じグループとアーティファクトIDを持っている限り、デプロイされたプロジェクトに同じjarの重複バージョンが表示されるのを防ぐことができます。
非常に単純なプロジェクトであっても、ソース管理システムへの依存関係をチェックすることに頼ることはないと思います。
サードパーティのライブラリだけではありません。ほとんどの場合、複数のリポジトリがある場合。私たちの場合、相互依存性と内部依存性がたくさんある4つのリポジトリがありました。実際、私はこの回答を開始し、誰かが他のlibディレクトリにある一方のプロジェクトの.jarを更新するのを忘れた後に発生した問題について、同僚と話をするために15分間行かなければなりませんでした。
そしてそれはより専門的に見えます:)