私はJNIを使用するJavaプロジェクトを作成します。私はスタンドアロンアプリケーションとしてプロジェクトを展開したいが、いくつかのモジュールは他のアプリケーションのライブラリとしても使用されるかもしれない。 私はさまざまなプラットフォームをサポートしたいと考えています。maven-nar-pluginとnative-maven-pluginのどちらが優れていますか？
私が見る限り、1年半前に更新されなかったmaven-nar-pluginと、より使いやすいnative-maven-pluginの選択肢があります私。
あなたはそのうちの1つまたは私が使用すべき推奨事項に関する経験がありますか？
スタンドアロンのC/C++アプリケーションにはmaven-nar-pluginしか使用していませんが、それは非常にうまく機能しています。
JNIに関しては、数年前からかなりの規模のアプリケーションでnative-maven-pluginを使用してきました。これを使用して、JavaアプリケーションがC APIのみを提供する他のアプリケーションとのインターフェイスをとることができます。私は実際にそれがかなり使いやすいことを発見しました。 documentationはかなり使いやすく、基本的な使い方について説明していますが、Cコンパイラやリンカ、そしてビルドに必要なオプションについても扱わなければなりません。
コンパイラとリンカーのコマンドとオプション、ソースの場所、およびjavahファイルの場所を渡すだけで動作します。私たちがJNIで行ってきた苦痛のすべてで、mavenプラグインは大した面倒ではないいくつかの事の一つだと言わざるを得ない。
スタンフォード線形加速器センターのマークDonszelmannによってNARプラグ約this presentationにおける第三のスライドはネイティブのmaven-プラグインとMaven-NAR-プラグインを比較します。スライド3からの引用、ネイティブのmaven-pluginのの長所と短所：
賛否
- 非常に設定可能
短所が
- が外に実行されませんでしたボックス（デフォルトなし）
- バイナリの依存関係なし
- ないクロスプラットフォーム（異なるプラットフォームごとに異なるプロファイルが）
私は1年以来、多くのネイティブのmaven-pluginのを使用しました、クロスコンパイル、各プラットフォーム用のプロファイルでCおよびC++のソースコードを（コンパイラ、コンパイラオプション、リンカオプションなどのオプション）。 それは魅力のように機能しますが、私の状況では一人で可愛いです。 C/C++開発者がまだ他の時代のmakeまたはcmakeツールを使用している理由を理解できません。 Mavenはバージョンや依存関係を管理する上で非常に優れています...
GitHubページは2010年11月7日に更新されました... – khmarbaise
本当です。私はもともとこのページhttps://github.com/sonatype/maven-nar-pluginを見つけましたが、このリポジトリhttps://github.com/duns/maven-nar-pluginは最近更新されました。 – Cephalopod
maven-nar-pluginの開発は、GitHubフォークのいくつかを統合して、[独自のGitHub組織]（https://github.com/maven-nar/maven-nar-plugin）に移行しました。 – ctrueden