2

ライブラリの依存関係を処理するために Apache Ivy を使用しています。私の会社には、定期的にリリース/バージョン管理される「コア」プロジェクトがあります。次に、特定のクライアント向けの多くの「顧客」プロジェクトがあります。各顧客プロジェクトは、顧客プロジェクトの ivy.xml で維持するコア プロジェクトの特定のバージョンを使用します。大丈夫だ。

ローカルでコアを変更し、特定のプロジェクトで変更をテストしたい場合があります。その場合、彼らはコアを構築し、共有リポジトリではなく、ローカルの Ivy リポジトリに公開します。

このローカルでビルドされたバージョンを取得するには、ローカルでビルドされたバージョンまたはコアが、ivy.xml でプロジェクトが指しているのとまったく同じ xyz バージョンで公開されていることを確認する必要がありますか? それとも他のアプローチがありますか？ivy.xml をいじる必要がないようにしたいと思います (たとえば、core -> latest.integration に変更します)。これは、誤ってソース管理にチェックインされる種類の変更であるためです。おそらくローカル プロパティ ファイルで、ivy.xml の依存関係のリビジョンをオーバーライドする方法があるのでしょうか?

4

1 に答える 1

1

開発では、プロジェクトの内部依存関係を常に「latest.integration」または「latest.release」として指定します。これにより、ソース管理にチェックインされたファイルをいじらないという問題が解決されます。

良いニュースは、ツタの公開タスクが動的なリビジョン番号を解決することです。リポジトリに公開されているivy.xmlファイルを確認すると、最新のリビジョン番号（公開時）が自動的に置き換えられていることがわかります。

ivy配信タスクは、ビルド内でこれを行うように設計されています。モジュールのMavenPOMファイルを生成するために解決されたivyファイルが必要な場合に使用します。

例えば：

<ivy:deliver pubrevision="??" status="release" deliverpattern="${build.dir}/ivy.xml"/>
<ivy:makepom ivyfile="${build.dir}/ivy.xml" pomfile="${build.dir}/pom.xml"/>

最後のヒントは、シーケンス内の次のバージョン番号を知る必要がある場合にivyビルド番号を使用することです。Ivyは、ivyリポジトリにすでに公開されているものに基づいてこれを解決します（プロパティファイルに依存する標準のANTビルド番号タスクよりもはるかに柔軟です）。

したがって、引き続き動的リビジョンを使用し、ivyに特定のリリースの実際のバージョン番号を計算させます。

于 2010-09-13T22:51:27.907 に答える