MavenとGradleを比べてGradleがいいんじゃないかなって思う理由
概要
すっごく前に作って安定稼働していたMaven(作った奴もこれ以上変えたく無いやつ)
を、ついに必要な部分だけGradleに変えた。
そのモチベーションになった
MavenとGradleの違い
について書く。
かなり致命的なレベルでいろいろちがう。
設定ファイル vs スクリプト
どこかでだれかが言ってたとおり、
MavenとGradleの最大の違いはそこかな、って自分も思ってた。
Mavenは設定ファイル
Gradleはスクリプト。
自分で手を汚してみた結果、
差分の表現としてはちょっと足りないかな、って思う事がこの移行に際してあったので、次に挙げる。
エラー検出力
設定ファイルのミスを見つけるのがmaven。
スクリプト実行の内容エラーを吐くのがGradle.
設定ファイルの出す答えって、処理内容単位でのOKかErrorの二択だよね。
ずーっと人任せだったんで、ほぼ初めてmaven触ってみた時の感想として、
判りづらい！！！ って思ってしまった。
Gradleだと、プログラムを順次実行してく感じになる。
どこでエラーが出たか、については、ここまでは同じ。
で、Gradleだと行にprintlnとか入れられるのです。
何処まで行ってどんな状態か、判る訳です。
エラー出力内容
Maven、何かあるとwikiに行けって書いてあるのは超イラついた。
追跡構造はしっかりしてるので、特に問題は無いと思う。
プラグイン読めば良いんじゃないの。そして絶望すればいいんじゃないの。
プラグイン内でエラーもみ消される事の方が多くてその辺については本当救いようがない。
Gradle、行単位でエラー見れる。
が、エラー発生時には、Gradleのエラー表示も出て、それで根本的なエラー原因をシークする時間がちょっとずつ掛かるのが戴けない。
もしかしたらGradleのエラー表示部分だけ避ける、とかオプションあるのかな。
フォルダ/ファイルの扱い
プラグインがJavaで書かれていて内部でJavaプログラムでファイル作ったりするのがMaven
全部スクリプトで書かれてるのがGradle
正直、Maven触って一番がっかりしたのがフォルダ/ファイルに関して。
TODO:今まで触ってくれてたkrmdに感謝と懺悔の意を込めてメシおごる。
Mavenの「基礎コンテキスト」領域には、フォルダ・ファイル操作系APIが無い。
プラグイン内でファイル操作が必要なら、File.ioをインポートしまくり。
そこら中の.javaファイルでインポートしまくり。
Javaに限らないけど、プログラムでファイル処理扱うのってまず第一級の鬼門でしょ。
なぜならファイル処理は前提の多いシーケンシャルな処理だから。
有無を確認、正当性をチェック、フォルダか？、ファイルか？
その時どんな状態か、というのをValidateする必要に追われる。
そんな鬼門コードが、個別に書かれた複数のプログラムとして至る所にある。
個別にFile.ioで、読んで吐いて書き換えて消して。
ダメだろ。
全体的にファイルインプット/アウトプットについて扱う、大枠を用意して、
できるだけ一つのコンテキスト内でファイル作ったり消したりコピーしたりしましょうよ。
Write Everywhereになっちゃう処理があるってことは、それを上位に持ってこないと酷い目に遭います。
同じ処理を別のファイルに2つ書いた時点で気付こうぜ。
おかげさまで、
Create/Delete処理が各Java/Classファイルに分散、全体像が把握しにくい。
エラーチェックが部分部分になる。(Javaでtry~catchしても握りつぶすだけでしょクソが)
チェックを多重化せざるを得ない（チェックコードが増える、それもケース判断を限られたアスペクトで。無理。）
Javaのダメなとこスケールしてんぞコラ。しかもオートだ。
こんなものが世界中にばらまかれてるかと思うと虫酸。
フォルダ/ファイル扱うのが不自由ってだけでもう断定するけど、
Mavenは、依存性解決設定ファイルとそのビルダーであって、
アーキタイプ作成ツール/他に「なってはいけない、向いてない」
Gradleだと、FileIO系はデフォルトでAPIとしてGradleが動作する環境内にある。
ので、処理がばらける事は（デフォルト使ってくれれば）無い。
デフォルトで用意されてれば使うでしょ、ってのは理想論だけど、少なくとも機能が考慮されてる。
そうあれ、とデザインされてる。
ユーザー全体が同一アスペクト内でファイル操作が出来るメリットは、Mavenの抱えるデメリットが無い事。
どこかに書かれてる筈なんだ、とPluginの素のJavaファイルをがさごそすることは、無い。
エラーも、必ず最前面に出て来る。少なくともtry~catchが存在するのはgradleファイルだ。
プラグイン作りの難解さ
Mavenだと、プラグイン用のpom書いて、Javaソース書いて、コンパイルして、パッケージして、
手元環境だったらinstall→実際に使うプロジェクト側でmvn なにやら
めんどくせーーーーーーーー
そしてソースコード多ーい。 File.io多ーい。
Gradleだと、まだ数作ってないですけど、
ぶっちゃけスクリプトだから書いて実行すればいいんだわさ。
まとめ
比較うすッ！！ まあ俺が苦しんだのがこの程度の事だったんです。
そんな薄い結論:
ビルド+バージョンを纏めておく為の機構としてはMavenいい子。
それ以上の何かを求めるならGradleが良いと思う。
Mavenは、自分は何処から聞いたか忘れましたけど、
「ビルド+Archtypeとかが色々出来るツール」として聞いてたんですが、これ、ビルド以外全部無理でしょうや。
プロジェクトのビルドに関するArtifactバージョン定義と依存性解決ツール
ってだけだ。
Archtype生成や、test結果のGenerateの為には、どうしても「ファイルを扱う」ってのが
要件に入るのに、それを各プラグインのコード内で対処しようとしたのが設計ミスってると思う。
尻拭いとして「凄く良く様々なケースで失敗する」ってのが出てきちゃう。
裏を返せば、「ハマると強い」なんだけど。ハマる所が狭いだけでしょ。
それって、「想定できてる奴しか出来ませんしその条件ってのも暗黙化しててほぼ明示しませんけど、
使いたければどうぞ、探ってw 試してw 読んでww 苦しんでww」っていう。
お勧めされたら、
「ぜひ一人でお苦しみください」って返したい気分ですはい。
Gradleは、Mavenに出来る事は全部、Mavenよりスマートな方法で出来る。
後出しだからね、、！！
Architype作り、プラグインでのファイル制御、前提エラーの出し方、これらは、 Gradleの方が苦労も痛みも少ない。
コード=スクリプト=実行内容だから、そこに書いてないことは起こらない。
終いに
今までMavenを頑張って書いてきた人に敬意を表する。
凄いよ。大変だったでしょ。
もう、難しい方法でファイルとか扱わなくていいと思います。
File.ioをインポートしまくらないで良いと思います。
プラグインJavaで書いて、コンパイルして、それを含んだプロジェクト側でmvn なにやら。
大変だったでしょう。
build.gradleに何か書いて、gradle なにやら でOKになるんで。
もう苦しまなくていいんだょ。