5

JNI を使用する Java プロジェクトを作成します。プロジェクトをスタンドアロン アプリケーションとしてデプロイしたいのですが、一部のモジュールは他のアプリケーションのライブラリとしても使用される可能性があります。さまざまなプラットフォームをサポートしたいのですが、すべてが可能な限り簡単であるべきです。

私が見る限り、1年半更新されていないmaven-nar-pluginと、あまりユーザーフレンドリーではないように思われるnative-maven-pluginのどちらかを選択できます。

それらのいずれかについての経験や、私が使用すべき推奨事項はありますか?

4

3 に答える 3

5

スタンドアロンの C/C++ アプリにのみ maven-nar-plugin を使用しましたが、それは非常にうまく機能しています。

JNI に関して言えば、私はここ数年、大規模なアプリケーションで native-maven-plugin を使用しています。これを使用して、Java アプリが C API のみを提供する他のアプリケーションとインターフェースできるようにします。私は実際にそれがかなりユーザーフレンドリーであることがわかりました。ドキュメンテーションはよくできていて、基本的な使用法を説明していますが、C コンパイラーとリンカー、およびビルドに必要なあらゆるオプションを扱う必要があります。

コンパイラとリンカーのコマンドとオプション、ソースの場所、javah ファイルの場所を渡すだけで機能します。私たちが JNI で経験してきたすべての苦労を考えると、Maven プラグインは大きな問題にならなかった数少ないものの 1 つです。

于 2011-07-16T22:15:45.040 に答える
1

私は 1 年以来、C と C++ のソース コードをクロスコンパイルするために多くの native-maven-plugin を使用してきました (コンパイラ、コンパイラ オプション、リンカー オプションなどの各プラットフォーム オプションのプロファイルを使用して)。それは魅力のように機能しますが、自分の状況ではかなり孤独を感じます. なぜ C/C++ 開発者がまだ他の時代の make や cmake ツールを使用しているのか理解できません。Maven は、バージョンと依存関係の管理に優れています...

于 2014-03-01T22:21:47.803 に答える
1

Stanford Linear Accelerator Center の Mark Donszelmann による NAR プラグインに関するこのプレゼンテーションの 3 番目のスライドでは、native-maven-plugin と maven-nar-plugin を比較しています。スライド 3 からの引用、native-maven-plugin の長所と短所:

長所

  • 非常に設定可能

短所

  • そのままでは実行されませんでした (デフォルトなし)
  • バイナリ依存なし
  • クロス プラットフォームではない (プラットフォームごとに異なるプロファイル)
于 2012-09-14T18:36:50.930 に答える