これは正確に Gradle の問題ではありません。しかし、より一般的なビルドの問題です。以下のような構造のプロジェクトがいくつかあります。
-- A (by team 1)
-- build.gradle
-- settings.gradle
-- B (by team 1,3)
--build.gradle
-- C (by team 2)
-- D (by team 3)
これらは別個の CVS モジュールです。A、B、D は Java プロジェクトであり、2 つのチーム (チーム 1、3) によって管理されています。C は、別のチームによって管理される C++ プロジェクトです (2)。B は JNI 経由で C を使用します。(C が C++ であるという事実はそれほど重要ではありません。重要なのは、別のチームによって開発および管理されているということです。) 2 つのアプリケーションがあり、A はアプリケーション 1 の入り口であり、A->B->Cです。D はアプリケーション 2 のエントリ ポイントであり、D->B->C. 開発には、多くの場合、3 つのレベルすべての変更が含まれます。3 つのチームはすべて一緒に座り、常にコミュニケーションをとっています。実際には、私たち (チーム 1) は C のアプリケーション 1 にいくつかの変更を加える必要があるかもしれません。チーム 2 は C で作業し、一時的なコピーを提供します。統合後、さらに変更が必要になる場合があります。1つの問題に対して何回か往復します。アプリケーション 2 についても同様です。
現在、A、B、D はさまざまな ant スクリプトによって管理され、C は make によって管理されています。新しいツール、特に Gradle の調査を開始しました。最初のカットでは、A に B が (Gradle の意味で) サブプロジェクトとして含まれており、それらは常に一緒にビルドおよび公開されます。また、常に C のヘッド (Windows でソースからコンパイルしたもの、または最新の Jenkin ビルドを取得したもの) を使用し、ビルドに満足したら、3 つのプロジェクトすべてにタグを付けます。最近、内部 Artifactory リポジトリを採用しました。依存関係とバージョン管理をどう管理するかを考えています。完成したら、モジュール D のチーム 3 にも紹介します。
- C を A のサブプロジェクトとして含めて、3 つすべてを常に最初から構築することができます。同様に、C と B を D のサブプロジェクトとして含めます。たとえば、アプリケーション名をバージョン名に含めることができます。
- あるいは、リポジトリ内の固定バージョンの C に常に依存することもできます。
2 では、C のヘッド/スナップショットに完全に依存することはできません。これは、C の開発を伴い、不安定になる可能性があるためです。しかし、頻繁に変更する必要があるため、C の変更ごとに新しいバージョンを作成するのは非現実的です。
このような設定のベスト プラクティスは何ですか? インターネットで簡単に検索しても、あまり結果が得られません。誰かアドバイスをくれたり、本や文書を教えてくれませんか?
どうもありがとう。