4

一連の単純なプロジェクト A、B、C があり、それぞれが同じ共通プロジェクト Z を使用する必要があるとします。すべての部分は進行中です。

そこで、プロジェクト Z をライブラリとして A、B、C に追加します。

例の詳細: クラス A には単一のメソッド main() があります。クラス Z は単純な JFrame ベースのフォームです。Z には、フォームをインスタンス化する NB IDE のデフォルトの main() が含まれているため、個別に実行できますが、使用例では、A.main() は Z.main() を呼び出してフォームを表示します。

これは、クラス Z の単純なフォームでは問題なく機能します。

ただし、SwingX またはその他の非標準ライブラリからクラス Z のフォームにコンポーネントを追加するとします。これにより、対応するライブラリの依存関係がプロジェクト Z に自動的に追加されます。Z.main() を直接実行して Z をテストできます。正常に動作します。ただし、ここで A.main() を再コンパイルして実行すると、例外がスローされます。SwingX (またはその他の) ライブラリが見つかりません。

これは、Z の依存関係を A にも追加することで機能させることができます。したがって、問題は、プロジェクトをライブラリとして追加するこのメカニズムが、その他のライブラリ/プロジェクトの依存関係の追加を処理しないことです。

これに対する正しい解決策は何ですか？

ANT を使用する Netbeans 7.2。

チェックされた回答がないこれらの同様の質問の重複である可能性があります。

他のプロジェクトを netbeans のライブラリとして追加する

Netbeans - 現在編集中のライブラリを追加

4

1 に答える 1

3

この質問の主題は、次の NetBeans バグ レポートで説明されています: Bug 47507 - [40cat] Transitively required libraries not automatically added to runtime classpath

やや信じられないことに、これは 8 年以上にわたってアクティブであり、19 の重複した問題が発生する可能性があります。この問題には、長い議論のスレッドが付随しています。2008 年 1 月 10 日のユーザー「fommil」による、ある程度有用な回避策が 1 つあります。

「私の回避策は、すべての「[依存ライブラリ] プロジェクト」に対して、ライブラリマネージャーで「library.dep」というライブラリを定義することです。ここで、そのプロジェクトの依存関係のクラスパス、ソース、および javadoc を定義します。プロジェクトはこれまで「プロジェクト」に依存していたので、そのランタイム (およびテスト ランタイム) の依存関係に「project.dep」を追加します。

fommil は、そのアプローチの欠点についても議論を続けていますが、何もしないよりはましかもしれません。

とにかく、「解決」されていなくても、この質問は「回答済み」であると宣言します。

于 2012-12-04T02:50:02.353 に答える