私は私の個人的なプロジェクトのためにApacheのivyでantを使うようにビルドプロセスを修正しようとしています。これらは、いくつかの共有モジュールと、共有モジュールに依存するいくつかのアプリケーションモジュールで構成されています。この記事のために、共有モジュール（
common ）と common に依存するアプリケーションモジュール（
application コード>。各モジュールには独自の効果的なsvnリポジトリがあります：
svn_repo_1/common/trunk
/branches
/tags
svn_repo_2/application/trunk
/branches
/tags
関連するリビジョンを共通のワークスペースに、フラットな構造でチェックアウトします。
workspace/common
workspace/application
一般的に、 application は common
の公開バージョンに依存するため、 application
しかし、 application に必要な common
に新しい機能を追加する必要がある場合は、 application
（私のリポジトリに共通して公開する必要はありません）。
これは、 latest.integration が意味するもの（つまり、
application
のivy.xmlを変更して共通リビジョンのlatest.integrationを指定したもの）です。私の意図は、ivy
buildlist
タスクを使ってアプリケーションをビルドする前にビルドが必要なローカルモジュールを探すことでした。しかし、アプリケーションのivy.xmlファイルがlatest.integrationやその他の公開されたリビジョンを指定しているかどうかにかかわらず、
buildlist
タスクにcommon/build.xmlエントリが含まれているように見えるため、これは機能しません。
私は何か提案を感謝します。私はアイビーのドキュメンテーションとサンプルに苦労しているので、実際の例も参考になります。注：ここではMavenのソリューションに興味はありません。
うわー、これは本当にdeja vuです！ 3 –
4ヶ月前からこのサイトの私の最初の質問のいくつかに戻って、彼らはほとんどアイビー関連です！私はアイビーが学び、飼い慣らすのが難しい獣だと100％感謝しますが、それを専門的に数ヶ月使用した後、私は再びそれなしでは決して発展しません。だから私の最初のアドバイス：続ける。遅かれ早かれ、Apache
Ivyで見つけた小さな（実用的な）ドキュメンテーションはすべて意味を持ち始め、崩れ始めるでしょう。
なぜ common
をリポジトリに公開したくないのかを知ることができます。しかし、あなたが過渡的な依存性管理の新機能である場合、私があなたに与えることができる最初の実用的なアドバイスは、あなたのJAR/WAR
/その他をあなたのレポに常に公開するべきです。ワークスペースのローカルな「仲介」ではありません。
この理由は簡単です：Ivyには、設定ファイルで定義したリポジトリ（基本的に）をクロールする機能しかありません。これらの定義されたリポジトリの外にある
common
のようなJARを故意に保つと、（a）Ivyは推移的依存関係（主な仕事）を解決する方法がなく、（b） “下流”
common
を微調整するたびに動的に更新されません。したがって、IvyをJARを公開しないのみに使用することは、少し生産的です。私はアイビーがそれを機能として含むことさえ驚いている。
common を公開しないというあなたの動機を理解する必要があると思います。
ivy：publish
タスクを正常に動作させるのに問題がある場合は、心配する必要はありません。しかし、その他の理由がある場合は、複数のリポジトリを設定してください。
たいていすべてが公開される「プライマリ」リポジトリが1つあります。それであなたがそれを行うのが意味をなくても
common を公開する “二次”または “仲介”リポジトリがあります。次に、
publish-main や
publish-integration
など、2つの異なる公開タスクでAntビルドを設定できます。
そうすれば、あなたは両方の世界のベストを得ることができます：あなたはあなたの仲介のステージングエリアを手に入れ、アイビーの強力なコントロールの中にすべてを残すことになります。