免責事項: 私はプラグインの元メンテナーであり、org.codehaus.mojo
プラグインの作成者でもありnet.ltgt.gwt.maven
ます。
プラグインには、Maven で GWT を使用するための非常に異なるアプローチがあります。ここで最も重要なものを要約しようと思います。
まず、org.codehaus.mojo
は特定のバージョンの GWT に関連付けられています。これは、GWT の新しいバージョンがリリースされるたびに、違いを考慮して新しいバージョンのプラグインをリリースする必要があることを意味します。一方、すべての GWT オプション/フラグを構成プロパティとして公開し、Maven のドキュメント ( mvn gwt:help
) などを使用します。プラグインのバグが修正された場合、GWT のバージョンを更新して、次のプラグイン リリースで使用されるバージョンに一致させる必要があります。常に最新の GWT バージョンを使用する必要がありますが、他の依存関係が新しいバージョンと互換性がないなどの理由で迅速に更新できない可能性があるため、「バージョン競合地獄」に陥る可能性があります。
のnet.ltgt.gwt.maven
プラグインは、GWT の 2 つの最新バージョンとの互換性を目指していますが、さらに多くのバージョンと互換性がある可能性があります (テスト/保証されていないだけです)。これは、GWT とは独立してプラグインを更新できることを意味します。プラグインはand (and !) 依存関係をもたらします
。これは、厳密に同一でない場合、プロジェクトの依存関係からの競合を引き起こす可能性があります。また、Maven の動作方法が原因で、GWT の独自のフォーク バージョンを別の環境で使用する場合、それらをプラグインの依存関係から除外することはできません(依存関係を変更するには、プラグインを使用するか、プラグインをフォークする必要があります)。org.codehaus.mojo
gwt-dev
gwt-user
gwt-servlet
groupId
com.google.gwt
groupId
net.ltgt.gwt.maven
プラグインには、 と のカスタム が付属してpackaging
います。Maven を使用して GWT アプリを実行する方法については、非常に意見が分かれています: クライアントとサーバー (および共有) コードを個別の Maven モジュールに分離します (これは実際には The Maven Way™ に従っています: 個別のクラスパスが必要な場合は、別の Maven モジュールを使用する必要があります)。 、それぞれの依存関係)。もちろん、これらのパッケージを強制的に使用する必要はありません。適切なデフォルトと規則を設定することで、POM の構成を大幅に削減するだけです。gwt-lib
gwt-app
最後に、上記の「プロジェクト レイアウト」に関する独断的な見解のため、net.ltgt.gwt.maven
プラグインはマルチモジュール (別名リアクター) ビルドをサポートするように設計されていますorg.codehaus.mojo
。gwt:run
サーバーコードは「ライブ」です。マルチモジュール ビルドでは、mvn install
すべての依存モジュール (gwt:run
アグリゲーター モジュールで呼び出すことができないため) を使用する必要があり、 を使用build-helper-maven-plugin
して他のモジュールからクライアント ソースを取り込み、シームレスな開発エクスペリエンスを実現するなど、ひどいハックにつながります。
からプラグインに切り替えた gwt-maven-archetypes (免責事項: 私は作成者です) で、このコミットのプラグイン間の違いを確認できます。org.codehaus.mojo
net.ltgt.gwt.maven