0

私の組織は、マルチプロジェクト構成での依存関係管理に Apache Ivy を使用することを検討しています。ほとんどの開発が行われるメイン プロジェクト (MAIN と呼びます) と、別のリポジトリに保持するいくつかのヘルパー ライブラリ プロジェクト (LIBPROJ と呼びます) があります。現在私たちが行っているのは、ライブラリ プロジェクトが変更されたときにその jar を作成し、それらをメイン プロジェクトにコミットすることですが、これは大きな頭痛の種であり、プロジェクトの肥大化につながります。

アイビーのようなものを使用するのが適しているようです。Jenkins サーバーを使用して LIBPROJ 用の新しいライブラリ jar を自動的に構築し、それを ivy に公開し、「latest.integration」バージョンを使用して LIBPROJ の最新バージョンを MAIN に自動的に取り込むことを想定しています。しかし、いつ問題が発生したかを調べるために二分する必要がある場合、これはどのように機能するのでしょうか?

現時点でこれを行う唯一の方法は、LIBPROJ に変更が加えられるたびに MAIN で依存している LIBPROJ のバージョンを変更することですが、それは jar 自体をチェックインするよりもはるかに優れています。

私がこれについて心配している理由は、古いバージョンの MAIN を見る場合、1 つだけチェックアウトすると、最新のビルドを要求しているため、ビルドして実行することができないためです。今見ているのは、数日/数週間/数か月ずれている可能性があります。これにより、あらゆる種類の二分ツール (git や mercurial など) が壊れてしまいます。これは、私が本当にやりたくないことです。

4

2 に答える 2

1

動的リビジョンの使用は、ivy の通常の強力な機能です。サードパーティのプロジェクトが互換性のない変更を導入すると、新しいビルドの依存関係が失敗する可能性があるため、明らかに注意が必要です。

使用に関する私の推奨事項：

  • latest.release : 同一企業 (または協力企業) が作成したモジュール用。
  • latest.integration : 同じプロジェクト内の他のチームによって作成されたモジュール用

ここでのポイントは、変更を管理することです。動的リビジョンは内部の依存関係にのみ使用され、開発ビルドによって引き起こされたビルドの失敗に十分迅速に対応できるのは、共同作業チームを閉鎖することだけです。

サード パーティのオープン ソースの依存関係については、明示的なバージョンを設定し、アップグレードのために定期的に確認することをお勧めします。

最後に、古いビルドを再現する方法について懸念がある場合、利用可能な解決策は、リリースをカットするときに解決済みの ivy.xml のコピーをコミットすることです。アイビー デリバー タスクはこれを行うことができます。

<ivy:deliver deliverpattern="ivy-resolved.xml" pubrevision="${version}" status="release"/>

また、モジュールを Ivy リポジトリに公開すると、解決された Ivy ファイルのコピーもそこにあることを忘れないでください。

于 2012-07-27T22:37:04.560 に答える
0

あなたの最後の発言のため、latest.integration を使用するべきではありません。IMHO、最新のコンセプトは、同じリポジトリ内のプロジェクト間で特に役立ちます。そこでは、それらを一緒にクローン/チェックアウトすることが期待されます。

あなたと同様のケースで、バージョン番号の依存関係を使用しています。それでも、バージョン番号を自動的に更新できます。

次のようなスクリプトを作成できます (私のお気に入りではありません):

1) LIBPROJ ライブラリをビルドします

2) 次に、メインをチェックアウトし、その依存バージョンを変更します。

しかし、同僚に IVY を紹介するとき、私はこれを奨励しませんでした。LIBPROJ の新しいバージョンが必要な場合は、それを作成し、明確なリリースでプッシュします。

次に、MAIN の依存関係ファイルを変更します。

1) バイナリが膨張しません。

2) どのバージョンが現在使用されているかを追跡する感覚を生み出します。

3) バージョン管理。

于 2012-07-27T21:24:07.630 に答える