これは非常に長い間私を避けてきました。いくつかの gradle プロジェクト (ワークスペース内) が他の gradle プロジェクト (ワークスペース内) に依存していることをプラグインを使用して Eclipse が認識する方法があるかどうかはまだわかりません。 .
それらは相互に依存するのではなく、相互に公開されたアーティファクトに依存することになります。これらの他のプロジェクトがワークスペースに存在することを (コマンドラインで) 伝えながら、gradle が Eclipse ワークスペース ビットを作成するための eclipseClasspath Eclipse プラグインの一部として、ビルド スクリプトで明示的なサポートをコーディングする必要がありました。
これは面倒で保守できないだけでなく、ワークスペースに何があるか、それらのプロジェクトの名前、面倒なコマンド ラインなどについての既存の知識も必要とします。
これに対する解決策はありますか、それとも解決策はありますか?
例：
「A」という「商品」があるとします。「1つ」と「2つ」など、複数のgradleプロジェクトを含めることができます。これらは、A:one および A:two jar アーティファクトとして Maven または Ivy スタイルのリポジトリに公開されます。「2」は「1」に依存しているとしましょう。これを Eclipse にインポートできます。すべて問題ありません。Eclipse プロジェクト「two」は、maven/ivy リポジトリからダウンロードした one.jar ではなく、Eclipse プロジェクト「one」に依存します。
別の別の製品「B」があります。「foo」や「bar」など、複数のgradleプロジェクトも含まれています。「bar」は「foo」に依存し、「foo」はたまたま A:one に依存しているとします。まだ大丈夫です。「B」プロジェクトを Eclipse にインポートすると、「bar」プロジェクトと「foo」プロジェクトが表示され、「bar」は jar ではなくプロジェクトの「foo」に依存します。また、foo は自動ダウンロードされた A:one に依存します。瓶。
しかし、誰かが A と B の両方に同時に取り組まなければなりません。そのため、すべてのプロジェクトを Eclipse ワークスペースにインポートします。彼らは A:one で何かを変更し (バグを修正するなど)、B から何かを実行してそれを試したいと考えています。 Eclipse プロジェクト「1」。これにより、デバッグや検証などが複雑になります。プロジェクトの依存関係を手動で更新することは、次の依存関係の更新までの短い期間です。