問題タブ [target-platform]

私の理解では、プラグインの依存関係を設定する際に選択できるプラグインのセットは、アクティブなターゲット プラットフォームによって決定されます。

ターゲット プラットフォームを作成し、[設定] でアクティブなターゲットとして設定しました。依存したいプラグインが Eclipse の「コンテンツ」ペインに表示されます。しかし、依存するプラグイン プロジェクトの [依存関係] ペインでプラグインを「必要なプラグイン」として追加しようとすると、選択するリストに表示されません。未加工のマニフェスト テキスト エディターを使用して追加すると、Eclipse は依存するプラグインが [問題] ペインで見つからないと文句を言います。

私はこれが初心者なので、「プラグインされていますか？」（いわば）可能性が頭に浮かぶ、確かに可能性です。

p2、mavenなどは使用していません...ターゲットプラットフォーム定義にディレクトリを追加しただけです。

必要なすべての jar を含むターゲット プラットフォームを設定しているにもかかわらず、コードをコンパイルできません。ワークスペースをクリーンアップしてEclipseを再起動しようとしましたが、役に立ちませんでした。

そのフォルダー (すべての jar を含む) をビルド パスに含めると、正常にコンパイルされます。

助けてください！

Eclipse 4.4 Luna M5でEclipse RCPアプリケーションを開発しており、Guice 3.0を使用しています。 そこで、ターゲット プラットフォームに guice.jar を追加し、開発中のすべてのプラグインに対して、Eclipse のプラグイン マニフェスト エディターを使用してバンドル com.google.inject をプラグインの依存関係に追加できます。これまでのところ、すべて正常に動作しています。

今問題: Guice 支援注入 ( ) を使用したいです@Assisted。

そこで、guice-assistedinject.jar をターゲット プラットフォームに追加しました。(私は .target ファイル = Eclipse ターゲット定義ファイルを使用しています)。

.target ファイル エディターの [コンテンツ] タブで、Eclipse はcom.google.inject.assistinjectguice-assistedinject.jar のフラグメント バンドル 3.0 を正しく表示しますが、このバンドルまたはこのバンドルのエクスポートされたパッケージをプラグイン プロジェクトの依存関係に追加することはできません。発展しています。

プラグイン マニフェスト エディターで [追加] を押すとcom.google.inject.assistedinject、追加可能な依存関係のリストにありませんか? どうしたの？

Windows CE プロジェクトで、[プロジェクト] > [ターゲット プラットフォームの変更] を選択すると、現在のプラットフォームが Windows CE であると表示されます。

ただし、プロジェクト プロパティでは、プラットフォーム == 同じ ("Windows CE") ですが、ターゲット デバイス プロパティの値は "Pocket PC 2003 SE Emulator" です (ただし、ドロップダウンの多くのオプションの 1 つは "Windows CE デバイス" です)。

これはミスマッチですか？プラットフォームに合わせてターゲット デバイスを変更する必要がありますか?

この質問は以前ここで尋ねられましたが、質問には答えていません。MS インストーラー展開プロジェクトで警告/エラーを抑制するにはどうすればよいですか?

ありがとう

環境

Eclipse RCP 3.X アプリケーションに組み込まれる多数のプラグインを開発しています。Tycho がサポートする唯一のフレーバーであるため、P2 リポジトリに基づく単一のターゲット プラットフォームを使用します。

ターゲット プラットフォーム VS SCM

インターネットへのアクセスはかなり制限されています。プロキシを構成しても、公開されている P2 リポジトリにはアクセスできません。そのため、P2 リポジトリの zip をダウンロードしてソース管理に配置し、チームで共有してバージョン管理できるようにします。ただし、SCM の下でバイナリ コンテンツを保持することは、多くの場合、不適切な方法であると考えています。

ClearCase から Git への移行を準備しています。その一方で、ターゲット プラットフォームの管理方法をより良いものに変更することを検討しています。私たちはさまざまなシナリオについて考えてきましたが、それらの長所と短所を測定する経験がありません. これが私たちの反省の最初の結果です：

シナリオ 1: ターゲット プラットフォームに別の Git リポジトリを使用する

• 長所：
  • プラグインは共有されています
  • 後で、ターゲット プラットフォームの「物理的な」以前のバージョンに戻ることができます。
  • ターゲット プラットフォームの変更は、ファイルを操作するのと同じくらい簡単です
• 短所：
  • SCM のバイナリ
  • すべてのリポジトリ インスタンスは、ターゲット プラットフォームの全履歴を保持するために多くのディスクを使用します。

シナリオ 2: P2 リポジトリ管理用のプラグインで Nexus を使用する

• 長所：
  • プラグインは共有されています
  • 軽量リポジトリ:foo.targetファイルのみをバージョン管理する必要があります
• 短所：
  • 以前は Nexus を使用したことがありませんでした
  • ターゲット プラットフォームのコンテンツの変更はより複雑です
  • ターゲット プラットフォームのコンテンツのすべてのバージョンのアーカイブ コピーを手動で保持する必要がある

質問

クローズドな企業ネットワークで Git を使用してターゲット プラットフォームのバージョン管理をどのように処理しますか? 上記のシナリオとそれぞれの長所と短所についてどう思いますか? 他の解決策を提案できますか？