4

一連の関連プロジェクトをGitの管理下に置き（これらのプロジェクトはすべて、Gitリポジトリのトップレベルである同じワークスペースにあります）、デスクトップ（32ビット）からラップトップ（64ビット）に複製しました。だから私はどこでもそれらに取り組むことができます。ワークスペース.metadataフォルダーは除外されますが、プロジェクトフォルダー内のすべてが追跡されます。

ラップトップで複製されたワークスペースを開くと、次のエラーが表示されました。

Project 'project' is missing required library:
'/usr/eclipse/plugins/org.eclipse.swt.gtk.linux.x86_3.5.2.v3557f.jar'

明らかに、64ビットのEclipseには32ビットのライブラリがありませんが、これをどのように解決する必要があるのか​​興味があります。

そのライブラリは、Window Builder SWT /JFaceProjectテンプレートの一部として追加されました。Eclipseプラグインフォルダーにがありorg.eclipse.swt_3.5.2.v3557f.jarますが、それを探すようにクラスパスを変更しても機能しません（奇妙なことに、SWTが見つかりません）。.classpathSWT / JFaceプロジェクトのファイルの残りの部分を見ると、この特定のライブラリは、プラットフォーム固有の唯一のライブラリです。

ライブラリの両方のバージョンをに配置します。.classpathこれにより、コードをビルド/実行できますが、ビルドパスエラーを無視する必要があります。このエラーは、ラップトップの変更をプルバックするとデスクトップに伝播します。

ラップトップの64ビットjarを32ビット名にシンボリックリンクして、クラスパスがライブラリを見つけられるようにすることはできますか？別のより良い解決策はありますか？

更新：このタイプのプロジェクトは具体的なSWTフラグメントに依存する必要があるようです。したがって、より良い解決策が見つかるまで、両方のマシンで問題のフラグメントをシンボリックリンクして、コンパイラーを正しいフラグメントに誘導します。他のマシン（特にWindows）でプロジェクトをビルド/実行すると、!!楽しい!! でもそこに着いたらその橋を架けます。

4

4 に答える 4

1

ワークスペース全体でそれを行わないでください。個々のプロジェクトでそれを行うだけです。ここでうまく機能します。

于 2010-12-03T22:38:10.003 に答える
1

ソース管理で正確に何を維持していますか？

ベストプラクティスは、手書きのソースファイルのみをソースリポジトリに保持することです。バイナリ、生成されたファイル、またはIDE設定ではありません。

64ビットEclipseのIDE設定が32ビットEclipseで機能しないという問題があると思います。

ワークスペースのディレクトリを削除.metadataし、このEclipseのすべてのプロジェクトを再インポートするだけです。

于 2010-12-03T22:40:10.383 に答える
1

どのタイプのプロジェクトを開発していますか？Javaプロジェクトまたはプラグインプロジェクト？

プラグインプロジェクトを開発している場合、プロジェクトは具体的なswtフラグメント（swt.gtk、swt.win32など）に直接依存しないようにする必要があります。swtの実際の実装が異なるプラットフォームの異なるフラグメントであるかどうかは、ホストプラグイン'org.eclipse.swt'に依存する必要があります。

サードパーティの要件としてswtを必要とするJavaプロジェクトを開発している場合。32ビットと64ビットの両方のEclipseにEclipseDeltaパッケージをインストールできます。

于 2010-12-04T14:31:20.730 に答える
0

プラットフォームの問題を回避するために、Mavenを検討することもできます。プロファイルプラットフォームの問題をオプションで組み合わせてMaven2または3を使用すると、非常に簡単に解決できます。Eclipse用のいくつかのMavenプラグインを使用して、MavenプロジェクトをEclipseに直接インポートできます。

于 2010-12-04T14:54:36.670 に答える