5
  1. 私のMavenレポ（.m2）。sub_app-0.1.jar のようなローカル jar が 1 つあります。
  2. ivy-cache に同じコピーがあります。
  3. sub_appで実行するmaven installと、新しい sub_app-0.1.jar ファイルが作成されます。
  4. その後、実行するgrails cleanと、新しい sub_app-0.1.jar が .m2 から取得されません。

  5. しかし、sub_app-0.1.jar ファイルを ivy-cache から削除 (削除) して実行するとgrails clean、新しい sub_app-0.1.jar ファイルが ivy-cache に取り込まれます。

  6. サブアプリ pom と grails pom のバージョンを変更すると、Grails は最新のものを取得します。再インストールはかかりません。

  7. sup-app jar にも SNAPSHOT を追加してみました。同じ結果、初めて取ってからじゃない。

すなわち。Grails は、ivy-cache に jar 名とバージョンだけを考慮し、持っていれば - かかりません。持っていない場合 - .m2 から取得します。

ただし、新旧のビルドは考慮していません。

ステップ 4 でも同じ動作 (ステップ 5) を取得するにはどうすればよいですか?

4

3 に答える 3

0

更新しました

Grails ガイドで指定されているように、 BuildConfig.groovyの依存関係に changing=trueを追加してみてください。

compile ('YOUR_GROUP_ID:YOUR_SUB_AP:0.1') {
    changing = true
}
于 2013-05-13T11:56:38.647 に答える
0

これがあなたと同じ問題かどうかはわかりませんが、「インターフェイス」プロジェクト (インターフェイス、Bean、pojos などを含む) に依存する「grails」プロジェクトで Spring Source Tool Suite (STS) を使用しています。

STS のインターフェイスで maven インストールを実行すると、maven は最新の jar で正しく更新されます (バージョン番号として「-1.0-SNAPSHOT」を使用します)。

次に、STS の「grails」プロジェクトで grails clean を実行すると、Grails はインターフェイス jar の変更を正しく識別し (BuildConfig.groovy に {ching=true} があります)、pom をダウンロードしますが、jar を次のようにダウンロードできません。 ivy-cache から jar を削除することはできません。STS には、これを防ぐ ivy-cache のハンドルがあるようです。

このプロジェクトは、Grails や STS のバグ/機能であると知らされた別の開発者から継承したので、次のいずれかで彼の知識と回避策に頭を下げました。

  1. 「インターフェイス」にインストールする代わりにmavenパッケージをインストールしてから、最新のjarをivy-cacheにコピーします。STS では、jar の内容を交換できるようです。次に、grails clean は ivy-cache の最新の jar を使用します (maven からのダウンロードは試みません)。
  2. 「インターフェース」にmavenをインストールし、STSを閉じ、ivy-cacheからjarを削除し、STSを再度開き、mavenから最新のjarをダウンロードするgrailsをきれいにします。

どちらの回避策も苦痛なので、誰かアイデアがあれば興味がありますか?

于 2013-05-14T08:53:51.030 に答える