プロジェクト X がベース プロジェクトで、プロジェクト Y が X に依存しているとします。プロジェクト Y は、プロジェクト X のプラグインである場合もあれば、他の方法でプロジェクト X を必要とするスタンドアロン アプリである場合もあります。
プロジェクト Y はスーパープロジェクトであり、プロジェクト X はプロジェクト Y のサブモジュールであるべきだとずっと考えてきました。
しかし、これを読むと、私の考えが逆転しているように見えます。この記事では、依存関係はスーパープロジェクトであり、依存コード (この場合はプラグイン) はサブモジュールです。これはサブモジュールを使用する正しい方法ですか?
それは依存しますが、一般的なケースでは、サブモジュールは両方に対応している (または可能性がある) と言えます。
明らかに、プロジェクト Y がプロジェクト X の依存関係 (外部ライブラリなど) である場合、それはサブモジュールである必要があります。
ただし、サブモジュールは依存関係のためだけのものではなく、半独立して開発されたプロジェクトのコンポーネントであるアイテムのためのものです。プラグインはそのようなコンポーネントです。独立して開発されていますが、プロジェクトのソースと一緒にパッケージ化したい場合があります。
ProjectY が ProjectX について何も知らなくても生きていける場合 (これは X のプラグインである可能性があります)、それはスーパープロジェクトではありません。
何らかの形で X を完成させる必要がある場合、はい、ツリー内で X を参照するためにスーパープロジェクトである可能性があります (サブモジュールの真の性質で説明されているように)。
コンポーネントベースのアプローチでは、真のスーパープロジェクトは、プロジェクト全体が機能するために必要な正確な構成 (つまり、リビジョンのリスト) を記録するためにProjectYとProjectX の適切なバージョンを参照する 3 番目のプロジェクトになります。
OP は正しい質問を追加します: 依存関係 (X に対する Y) をどこに保存しますか?
コンポーネントベースのアプローチを採用し、ProjectZ スーパープロジェクトがあり、ProjectY がビルドするために ProjectX に依存している場合、ProjectX を ProjectY のリポジトリにサブモジュールとして含めるのではなく、ProjectZ にのみ含めますか?
これは、ProjectY を単独でビルドすることができず、(雄弁でないため) 一種の「暗黙のサブモジュール」になっていることを意味します。
コンポーネントが 2 つしかなく、一方が他方に依存している場合は、ProjectX を ProjectY のサブモジュールとして直接宣言できます。
ただし、ProjectY を単独でビルドできない場合、それは「完全な」(「自律型」のような) プロジェクトではありません。
したがって、グローバルな親 "ProjectZ" には、その依存関係情報を ProjectY の外に格納する利点があります。