Mavenのすぐ忘れること
pomの記法とか
filter
<filtering> tag にtrueをセットして置くと、リソース内の${propertiesで定義した名前}とかで値を置き換えることが可能
dependencyManagement
ココに記述した内容は即依存性として追加されないが、groupId, artifactIdごとにデフォルトのバージョンなどを定義できる。ここで指定していれば、dependenciesの中でバージョンを指定しなくても、dependencyManagementで指定したバージョンが使われる。
親Pom作ってそれを継承するものが複数いるときとかにバージョン揃えるのに非常に便利
マルチモジュールプロジェクトとかで、親pom内にのみバージョンを指定して子プロジェクトではバージョンをそのままにするというのをよくやる
bomプロジェクトを指定して関連プロジェクトのバージョンを簡単に管理することができる
bomプロジェクトに、関連するライブラリの必要なバージョンが全部書いてあるので、推移的なバージョンの依存性を意識しなくてよくなる
これは良い例だと思ったけど、あるバージョンのarquillianのbomをdependencyManagementへ書いておけば、arquillianの実ライブラリたちのバージョンを意識しなくても、bomで定義されている正しいバージョンを依存に加えることができる
pluginManagement
plugin向けのdependencyManagementという理解
親PomのpluginManagementに記述しておけば、子供のpomではバージョンとか指定せずにpluginを利用することができる
scope
table: scopeの種類
種類 内容
compile デフォルト値。全ての状況でクラスパスに追加される。
provided ライブラリが JDK やコンテナによって提供される場合に指定。コンパイル時のみクラスパスに追加される。
runtime 実行時のみに必要な場合に指定。テストの実行および通常の実行のときにクラスパスに追加される。
test テストのときのみ必要な場合に指定。テストのコンパイルと実行のときにクラスパスに追加される。
system システムのライブラリを明示的にクラスパスに追加する場合に指定。リポジトリを検索しない。
packaging
table: packagingの種類
種類 内容
jar デフォルト。
war
ear
pom pomプロジェクト。マルチモジュールプロジェクトのrootのpomとかはこれを指定する。
optional
trueにするとクラパス上で依存が使われない限りはその依存はpackagingされない
たとえば開発時だけ使うツールとかをoptional=trueにしておけば、jarとかには依存がpackagingされなくなり、開発時だけ有効にできる
ビルドライフサイクル
ココがよくまとまってた
plugins
mavenでは全ての処理がプラグインによって実現されています。←これ重要
ライフサイクルの各フェーズで行われる処理は実際はプラグインが持つ処理が実行されています。
mavenではフェーズとプラグインが持つ処理(ゴール)を紐付けることにより、フェーズを指定するだけで処理が実行される仕組みになっています。
上記で説明したように、フェーズとゴールを紐付けることでフェーズを指定するだけでゴールが実行されます。
mavenではそれぞれのライフサイクルのいくつかのフェーズはあらかじめゴールが紐付けられています。
core plugins
process-resources -> resources:resources
compile -> compiler:compile
maven.compiler.source, maven.compiler.target に指定されたJavaのversionでコンパイルしてくれる
process-test-resources -> resources:testResources
test-compile -> compiler:testComiile
test -> surefire:test
maven-surefire-plugin
テストの実行してくれるplugin。
pluginで指定しなくても、maven testを実行するとsurefireが動いてテストが実行されている
ただし、デフォルトのバージョンだと低いのでJUnit5がうまく動かなかったりする
コマンドラインからのpluginの省略呼び出し
mvn sample.plugin:hello-maven-plugin:sayhi -> mvn hello:sayhi で呼び出せる
${prefix}-maven-plugin or maven-${prefix}-plugin の命名に沿っていれば上記の省略が適用できる
アーティファクトの複数バージョンが競合したときのMavenの依存性解決の仕組み
基本はpom.xmlから一番距離的に近いバージョンのものが使われる
ある依存内に含まれる推移依存を取り除いて依存性の競合を手動で解決する
exclusionで特定の推移依存を取り除くことが可能
その他
exec plugin
exec:exec
Javaを含めた、任意のプログラムの実行
npmとかも実行できるよ
exec:java
Javaプログラムの実行
Javaの実行に特化したパラメータとかになってるので、Java実行するならこっちが便利よ
jar作るpluginたち
xxxx.jarにメイン・マニフェスト属性がありません はだいたいmainClassの指定不足
maven-jar-plugin
そのプロジェクト配下のclassやresourceのみのjarを作る
maven-assembly-plugin
uber jar作れるけどクラス名が競合したら問題になるので、小さいプロジェうと向け
maven-shade-plugin
uber jar作れて、クラス名が競合した場合も設定で再配置して競合を解決可能
maven-failsafe-plugin
integrationテストのplugin
kotlin-maven-plugin
kotlin入れるときに追加する
build-helper-maven-plugin
profileごとにsrcフォルダを分けたりできる
同じプロジェクト内で同名クラスが存在しちゃうとどちら使えばいいか見分けつかなくてコンパイルエラーになる
devプロファイル内で依存と同名のパッケージ&クラスを定義してやれば置き換えたりできる
devのときだけダミーのクラスに置き換えたりできるので結構べんり
一応srcフォルダ追加する以外にもresourceフォルダ追加したり色々できるんやな
やりたいこと別
profileごとにsrc, resourceを分けてビルドできるようにしたい
mavenのprofilesの記述とbuild-heloper-pluginを使えばかのう
サンプル
複数プロファイルのresourceフォルダに同名プロファイルがあった場合先勝ちになるのでdevプロファイルとかつくったらresourceは先に定義してやるのがよい
srcはbuild-helper-maven-pluginでやる感じで
その他
同じphaseのgoalが複数指定されていたときの順番
同じphaseに複数goalが指定されていた場合、pom.xmlの定義順に実行される
mvnwの導入
READMEのコマンド叩くだけ
mvn wrapper:wrapper 叩くだけ