これは実際には2つの質問ですが、同じ問題から来ています。
- Jenkinsを継続的インテグレーションシステムとして使用します。誰かが変更をコミットするたびに、Jenkinsはそれを構築します。
- 私たちは企業のMavenリポジトリ（Artifactory）を使用しており、私たちが構築する他のプロジェクトに必要なすべてのjarはそこに保存されます。
- Jenkinaのプロモーションプラグインを使用して、Jenkinsビルドをプロモーションします。ビルドをプロモートするときは、
mvn deploy:deploy-fileコマンドを使用して、そのビルド内のjarとそれに関連するPOMを企業のMavenリポジトリにデプロイします。 - 実際にはAntでIvyを使用していますが、とにかくMavenリポジトリを使用しています。
質問が出てきました。開発者は、プロジェクトAによって構築されたjarを使用するプロジェクトBに取り組んでいます。開発者はプロジェクトAを変更し、その変更されたjarをプロジェクトBで使用したいと考えています。
最初の質問
を使用し<ivy:publish>て、そのjarをそのコンピューターのローカルリポジトリに配信できると思います。次に、その開発者がビルドを行うと、企業リポジトリのjarの代わりに、そのバージョンのjarが使用されます。
ただし、checkmodifiedivysettings-public.xmlがtrueに設定されるようにIvyを設定しました。これは、リポジトリに異なるバージョンのjarがある場合、それがすでにローカルリポジトリにある場合でも、それをダウンロードすることを意味します。これは、jarをローカルリポジトリに公開する開発者の機能にどのように影響しますか？
Ivyが依存関係を解決するとき、ローカルマシンへの依存関係がパブリックリポジトリにあるものとは異なることに気付くので、常にパブリックjarをダウンロードしますか、それともIvyはタイムスタンプを使用しますか？つまり、Ivyは、ローカルjarのタイムスタンプが企業リポジトリのjarのタイムスタンプよりも新しいことを確認するため、企業リポジトリのタイムスタンプをダウンロードしません。
必要に応じて、checkmodifiedをfalseにリセットできますが、最新バージョンのjarを取得するには、定期的にIvyキャッシュをクリーンアップする必要があることを開発者に通知する必要があります。
2番目の質問
他のプロジェクトに影響を与える可能性のあるベースjarの変更の問題をどのように処理しますか？
私の現在のモデル（私が行った仮定）では、これらのjarファイルを企業のMavenリポジトリーに配置するための何らかのワークフローを期待していました。誰かが問題を作成し、ワークフローを経て、そのjarをMavenリポジトリにデプロイします。
ただし、これは制限が厳しすぎる可能性があります。たぶん、ベースjarのデプロイ（特に多くの開発作業が行われている場合）は少し緩いはずです。
- 私はこのワークフローモデルを主張することができました。私はCMであり、私の言葉は法律です。しかし、私は物事を設定するので、開発者は自分の仕事をすることができ、ナンセンスな手順の束に従うことはできません。
- 私に尋ねる代わりに、プロジェクトリードに展開を許可することができます。このようにして、彼らは彼らが宣伝する瓶の品質を決定する（そして責任を取る）ことができます。
- 設定できるので、Jenkinsは特定の条件下でjarを自動的にプロモートします（すべての単体テストに合格するなど）。これを手動デプロイメントと組み合わせることもできます。開発者はjarをプロモートできますが、単体テストに合格したものだけです。また、単体テストに合格しなかった場合でも、プロジェクトリーダー（または自分自身）がjarをプロモートできるように設定することもできます。
最後に、私は会社でIvyをセットアップしたので、すべてのプロジェクトを完全に制御できます（ Ivyをすべてのプロジェクトに取り込むためにivysettings.xml使用します）。svn:externals
私にできることの1つは、2番目のスナップショットリポジトリを設定することです。Jenkinsビルドが完了すると、jarはこのスナップショットリポジトリに自動的にデプロイされます。開発者がAntプロパティをビルドに（コマンドラインまたはファイルを介して）渡すことを許可できます。これにより、開発者はリリースリポジトリの前にスナップショットbuild.propertiesリポジトリのjarを使用できるようになります。
Jenkins could be setup to always deploy newly built jars to this snapshot repository, bur. I would still control the deployment of jars into our release repository. Official (Jenkins) builds will always use the release repository, but developers can use the snapshot one if needed.