2

メインアプリケーションであるAndroidProject(A)があり、AndroidライブラリProject(B)を参照しています。ライブラリプロジェクトは、多くのJavaおよびAndroidプロジェクトの標準ライブラリである標準Java Project(C)を参照しています。これらの3つのプロジェクトをA、B、およびCと呼びます。

私の問題は、Cプロジェクトに変更を加えると自動コンパイルされますが、Bはコンパイルされないため、Aは変更を認識しません。これを行う唯一の方法は、Bを手動でクリーニングすることです。Eclipseで、Cのコンパイル時にBを強制的に再コンパイルする方法はありますか?

ADT14およびSDK14でのEclipse3.6.2の使用。

4

3 に答える 3

2

ADT 14でもこの問題が発生しました。私の場合、間接参照が少なくなっています(プロジェクトAはPLAIN Javaライブラリ(Androidライブラリではありません)、プロジェクトBはAndroidアプリです)。

本当に楽しかったのは、2つのプロジェクト「B」(2つのAndroidアプリ)があり、1つが機能していたことです。もう1つは、プロジェクトファイルのコピーを含む、正確なコピー(ベータリリースのマイナーな変更を含む)でした。

正常にコンパイルされましたが、ベータ版でライブラリファイルをパッケージ化できませんでした。

プロジェクトを削除し(ファイルを削除せずに)、再度追加しました。次に、アプリのビルドパスを再構成し、Javaライブラリを削除しました。次に、再構成して再度追加しました。

クリーン/ビルドすると、それらが再び正しくパッケージ化され始めました。

また、前述のビルド順序のトリックも行いました...それ自体は役に立ちませんでしたが、後のEclipseリフレッシュ作業に貢献した可能性があります(ライブラリプロジェクトが他のプロジェクトよりも先にビルドされていることを確認してください)。

于 2011-11-24T03:38:08.203 に答える
0

ADT 20でもまったく同じ問題が発生しました。コメントと受け入れられた回答を組み合わせると、ライブラリプロジェクトを[プロジェクトのプロパティ]->[Javaビルドパス]->[注文とエクスポート]で最初に移動することで解決したことがわかりました。

于 2012-09-09T02:10:30.040 に答える
0

プロジェクトA(通常のjava)を参照するプロジェクトB(android)で受け入れられた答えを試しました。プロジェクトBを削除してワークスペースに再追加した後、プロジェクトAをプロジェクトBの必要なプロジェクトから削除し、プロジェクトBを再追加し、プロジェクトAの順序/エクスポートでプロジェクトBにチェックマークを付けて一番上に移動し、最後にすべてをクリーンアップ/ビルドします。問題は解決されませんでした。クリーンアップとビルドの後、すべてが最新の状態になりました。しかし、IUがAで何かを変更した場合、その変更はBでは表示されませんでした。

私の解決策:

Androidプロジェクトのビルドパスで:-[ソース]タブを選択します-[ソースのリンク]をクリックします-Javaプロジェクトのsrcフォルダーを選択します。LinkedInSourceという名前を付けます-適用、クリーンビルド-成功

この解決策は理想的とは言えません。最初に他の解決策を試すことをお勧めします。

欠点があります。eclipseは、linkedLibrarySourceフォルダーをAndroidプロジェクトに追加するようになりました。これには、libのsrcフォルダーと同じファイルが含まれています。Eclipseはそれらを異なるものと見なします。これは、2つの場所で同じファイルを編集して、競合を引き起こす可能性があることを意味します。したがって、linkedLibrarySourceには触れないでください。

ADT20を使用しています

于 2013-01-06T17:51:43.327 に答える