Welcome, Java Hipsterこんにちは、ソリューション開発部の瀧口です。
突然ですが、JHipsterをご存知でしょうか?

ご存じない方のためにごく簡単に言うと、サーバーサイド SpringBoot + フロントエンド Angular (1 or 2) という、大変「いまどき」っぽいコードを生成する Yeoman のジェネレーターです。

単にソースコードを生成するだけに留まらず、JHipsterはビルドツールや実行環境、果ては SonarQube によるコード品質管理まで整えてくれます。 フロントエンドのビルドは yarn、サーバーサイドは Maven or Gradleが即実行可能な状態で用意され、yarn startmvnw を実行するだけで、Live Reloadingが有効な状態で開発を始めることができるんです。

今回は、JHipsterが生成するサーバーサイドの中で、ソースコード以外の部分で個人的に「おっ?」と思ったことについて、あれこれ紹介したいと思います。

前提

今回使用したのは、JHipster v4.0.8で、以下のオプションで生成しています。

Gitまわり

VCSは、当然のようにGitです。JHipsterのバージョンアップも、自動でブランチを作成してマージする、みたいな操作をしてくれます。

.gitignore

Eclipse/IntelliJ/VS Code の設定ファイルやWindows/OS X特有のファイルなど、毎回除外するものが最初から書いてあるのはありがたいですね。 SASSを選択した場合はコンパイル後のCSSを除外する設定なども入ります。

.gitattributes

ファイルの改行コードをLFに統一し、テキスト/バイナリの指定も一通り行われています。

コーディングまわり

EditorConfig って知りませんでした。対応しているテキストエディタであれば、インデントや文字コードの統一ができるんですね。 とはいえ、細かいフォーマット指定は(当然ながら)対応しないので、Eclipse / IntelliJ 混在環境の悩みがなくなるわけではなさそうです。

Typescriptは tsconfig.jsontslint.json が生成されるので、スタイルが統一できそうです。

Mavenまわり

JHipsterではMavenかGradleかを生成時に選べるのですが、私はMaven派なので。。。

オプションの選択にもよりますが、Mavenでは1000行ほどの pom.xml が、Gradleの方は 200行ほどの build.gradle + gradle/xxx.gradle 10個程度が生成されます。

Maven Wrapper

Maven v.s. Gradle戦争の中で、何度「Gradleは gradlew で即実行できる」の破壊力にやられたことか。 何度「Mavenのバージョン違う(からビルドできない)」を乗り越えてきたことか。。。

だがしかし、今や我々にもあるのだよ。この mvnw がな!!!

はい。というわけで Maven Wrapper です。 Maven使うならもう絶対入れましょう。Maven Wrapperを既存のMavenプロジェクトに入れるには

mvn -N io.takari:maven:wrapper

とするだけですよ。

POM全体像

上からざっと眺めてみると、こんな構成になっています。

  • 親POMに spring-boot-starter-parent
  • パッケージングは war (src/main/webappディレクトリもある)
  • たくさんの properties
  • たくさんの dependencies
  • ビルドライフサイクルにたくさんのプラグインを仕込む build
  • dev, prod等複数の profiles

これらを詳しく見てみましょう。

親POM指定の parent

SpringBootの流儀にのっとり、parentspring-boot-starter:1.5.2.RELEASEです。SpringBootおよびSpring周りの依存jarバージョンは、これで解決されています。特段変なことはされてない、いたって普通のSpringBootプロジェクトですね、ここは。

WAR指定の packaging

ここで「おっ?」ってなります。jarではなくwarです。とはいっても Executable JARを捨てているわけではなく、後述する本番向けビルドでは Fully Executable な WAR が生成されます。

フロントエンドのファイルはJavaのクラスパス上に存在する必要はないので src/main/webapp に置き、トランスパイル後の生成物がうまく war に含まれるよう、ビルド設定がなされています。

たくさんの properties

主にspring-boot-starter-parentがもたらすspring-boot-starter-dependenciesに書かれていない依存JARのバージョン、Mavenプラグインのバージョンが定義されています。

project.testresult.directoryが定義されているのは、テストレポートをフロントエンド側と同じ場所に出力させるためですね。その辺に集約されたものを、sonar.** の設定でSonarQubeに読ませるような設定にされています。

たくさんの dependencies

たくさんありますので、目に付いたものだけ。

JHipster

JHipster自身のAutoConfiguration含め、本番環境でのみ有効化されるキャッシュ制御フィルターなどいくつかのユーティリティがある、小さなモジュールです。

Dropwizard Metrics

実行中のメトリクスを収集するDropwizard Metricsが入っています。DBコネクションプールにHikariCPが選ばれているのも、Dropwizard Metricsに対応しているからでしょうか。

Springと統合する metrics-spring も用意されており、JHipsterは実行時間計測用のアノテーションを付けた状態でControllerを生成します。

Swagger

REST APIの設計、テスト、ドキュメント生成に力を発揮する便利なやつ、Swaggerです。JHipsterでは swagger プロファイルで有効になります。

Ehcache

JSR-107 javax.cache API の実装Ehcacheですね。hibernate-jcache で使われています。

Liquibase

Ruby on Railsで使われる、Active Recordのmigrationみたいなことをしてくれる、データベースのスキーマ管理ツールです。昔「Evolutionary Database Design (データベースの進化的設計)」という言葉が出てきたときからありましたね。

JHipsterでは、テストはSQLite、実行時はMySQL、のように異なるデータベース製品を同時に扱うので、DDL文そのものではなく、DB非依存でスキーマ管理できるLiquibaseのようなツールが必要になるのでしょう。 Yeomanでモデルを生成するコマンドを行ったときには、Java/Typescriptのみならず、Liquibaseのチェンジセットも生成される等、JHipsterに深く統合されています。

MapStruct

EntityとDTOのMapperを、Interfaceとアノテーションから自動生成するものです。現在のバージョンは Lombok と互換性が無いようで、「あれ、Lombokが無いな?」と思ったらこんなところに理由があったのか、って感じです。 次バージョンの1.2.0ではLombokと共存できるようなので、おそらくJHipsterにもLombokが入るんじゃないでしょうか。 と思っていましたが、コミッターが相当なLombok嫌いな模様・・・ 確かに特定のIDEで特定のプラグインが必要になるから、という理由は納得感ありますね。必要なら自分で追加しろってことで。

Spring Boot

spring-boot-actuatorを初め、良いものは大体入っている印象です。

spring-boot-starter-tomcatが外され、代わりにspring-boot-starter-undertowが使われています。 パフォーマンスが良いのと、Tomcat 8でキャッシュ周りのエラーが起こるのが理由みたいですね。 Issue #2948で移行を試みたがWindowsの呪いで諦め、再挑戦した Issue #4054 で無事にマージされたあたり涙無しでは語れない。

おもてなし build

コミッターの几帳面さがにじみ出てきます。きっとA型ですね。

sortpom-maven-plugin

POMの要素を名前順にソートしてくれるプラグイン。verifyフェーズに紐づけられています。

JHipsterが生成するPOMはソートされてないので、リリース前に突然diffが出たりしないよう、最初に mvn verify してからコミットするのがオススメ。

maven-resources-plugin

普段使うものですが、*.xm1*.yml# で囲まれた文字列を置換する設定が入っています。 application.ymlspring.profiles.activeを、Maven Profileを元に設定するようになっています。

普通のSpring Bootアプリケーションのように、実行時に外から(jarと同じディレクトリに置いたapplication.ymlなど)で上書きすることも可能ですので、あくまで初期値ということで。

jacoco-maven-plugin sonar-maven-plugin

テストカバレッジが計測されるようになっています。sonar はライフサイクルにバインドされていないので、mvn clean test sonar:sonarで実行する必要がありますね。

SonarQubeサーバーがない場合でも、JHipsterがDockerコンテナ設定を生成してくれるので、すぐに用意できます。

spring-boot-maven-plugin

parentspring-boot-starterなので本来不要ですが、<configuration>の上書きをしています。Linux環境でデーモン起動できる Fully Executable Jar になるよう <executable>true</executable> にされてます。

※Executable Jar は java -jar hoge.jar で実行できるもの。Fully Executable Jar は ./hoge.jar で実行できるもの、と理解するとよいです

docker-maven-plugin

ビルド成果物をDockerコンテナに配備して実行できるようにしています。Windowsで開発していると、正直あまり馴染みがないです、Docker。Vagrantは使うんですけどね。

複数の profiles

通常はデフォルトのdev、リリースビルドするときはprod、IDE使わない派はccを、必要に応じて使い分ける感じです。

まとめ

以上ざっくりとJHipsterが生成するものを見てきましたが、いかがでしょうか。

私個人の感想として、これまで知らなかったもの(Dropwizard Metrics、Mapstruct)、知っていたけど検証してなかったもの(Liquibase、Docker)が投入されていて、サーバーサイドの進化を感じます。

JHipsterそのものを実案件に投入するかはもうちょっと検証が必要ですが、JHipsterで使われている要素のうちいくつかは、そのまま既存プロジェクトにも適用できそうです。(Maven Wrapperとかね!)

皆様も自身の知識をアップデートする機会だと思って、JHipsterに触ってみてはいかがでしょうか。新しい発見がきっとあると思います。

 

この記事が気に入ったら
いいね!しよう

最新情報をお届けします

Twitter で「株式会社アークシステム」をフォローしよう!

JHipsterから学ぶ最近のJava開発事情https://devlog.arksystems.co.jp/wp-content/uploads/2017/03/morning_coffee_hires-1200x795.jpghttps://devlog.arksystems.co.jp/wp-content/uploads/2017/03/morning_coffee_hires-150x150.jpgtakiguchiプログラミング開発環境・ツール気になるJava,JHipster,Maven,Spring Bootこんにちは、ソリューション開発部の瀧口です。 突然ですが、JHipsterをご存知でしょうか? ご存じない方のためにごく簡単に言うと、サーバーサイド SpringBoot + フロントエンド Angular (1 or 2) という、大変「いまどき」っぽいコードを生成する Yeoman のジェネレーターです。 単にソースコードを生成するだけに留まらず、JHipsterはビルドツールや実行環境、果ては SonarQube によるコード品質管理まで整えてくれます。 フロントエンドのビルドは yarn、サーバーサイドは Maven or Gradleが即実行可能な状態で用意され、yarn start と mvnw を実行するだけで、Live Reloadingが有効な状態で開発を始めることができるんです。 今回は、JHipsterが生成するサーバーサイドの中で、ソースコード以外の部分で個人的に「おっ?」と思ったことについて、あれこれ紹介したいと思います。 前提 今回使用したのは、JHipster v4.0.8で、以下のオプションで生成しています。Gitまわり VCSは、当然のようにGitです。JHipsterのバージョンアップも、自動でブランチを作成してマージする、みたいな操作をしてくれます。 .gitignore Eclipse/IntelliJ/VS Code の設定ファイルやWindows/OS X特有のファイルなど、毎回除外するものが最初から書いてあるのはありがたいですね。 SASSを選択した場合はコンパイル後のCSSを除外する設定なども入ります。 .gitattributes ファイルの改行コードをLFに統一し、テキスト/バイナリの指定も一通り行われています。 コーディングまわり EditorConfig って知りませんでした。対応しているテキストエディタであれば、インデントや文字コードの統一ができるんですね。 とはいえ、細かいフォーマット指定は(当然ながら)対応しないので、Eclipse / IntelliJ 混在環境の悩みがなくなるわけではなさそうです。 Typescriptは tsconfig.jsonとtslint.json が生成されるので、スタイルが統一できそうです。 Mavenまわり JHipsterではMavenかGradleかを生成時に選べるのですが、私はMaven派なので。。。 オプションの選択にもよりますが、Mavenでは1000行ほどの pom.xml が、Gradleの方は 200行ほどの build.gradle + gradle/xxx.gradle 10個程度が生成されます。 Maven Wrapper Maven v.s. Gradle戦争の中で、何度「Gradleは gradlew で即実行できる」の破壊力にやられたことか。 何度「Mavenのバージョン違う(からビルドできない)」を乗り越えてきたことか。。。 だがしかし、今や我々にもあるのだよ。この...ARK Solution Development Division Developers Blog.