Groovy/超お手軽Web開発(Groovy-1.8 + Jetty8, 201209版) でGroovyServletを使った非常にミニマルなWeb開発環境を紹介しました。今回はもう少し掘り下げて、実際にServletやJavaソースを組み合わせ、Tomcat上でclassファイルの自動リロード(Context auto reload)も有効にした「サクサク開発」が出来る構成を作ってみたので、紹介します。
サンプル:
ポイント:gradle-tomcat-plugin を使う + Java/Groovyクラスファイルの出力先を"/WEB-INF/classes/"以下に設定する。
gradle-tomcat-plugin:
検証環境:
Win7 64bit JDK7 64bit Gradle 1.4
以下のように、実際に開発の現場で使いそうなポイントを組み込んでいます。
ということで、ソースの詳細についてはGitHubで眺めていただき、ポイントとなる部分だけを紹介していきます。
gradle-tomcat-pluginでは、"tomcatRun"タスクでTomcatを立ち上げる際に、Contextの"relodable"をデフォルトで有効化します。
これにより、"/WEB-INF/classes"および"/WEB-INF/lib"以下のファイルに変更があれば、Tomcat側で自動的にContextをリロードしてくれます。
ターミナルを3つ立ち上げ、1つは"gralde tomcatRun"でTomcatを起動させておき、2つ目ではエディタを立ちあげてソースファイルを編集し、3つ目で"gradle classes"を実行する、のような形で、コンパイルされたクラスを即座にTomcatに反映させる「サクサク開発」が実践出来ます。
ただし注意点が1つあります。GradleのJava/Groovyクラスファイル出力先はデフォルトでは以下のディレクトリです。
build/classes/...
また、warプラグインが想定するデフォルトの"/WEB-INF/"ディレクトリは以下になります。
src/main/webapp/WEB-INF/...
gradle-tomcat-pluginは、クラスファイルの出力先を設定から取得してContextに追加し、起動するため、基本的に上記のようなデフォルトのままでも起動自体は問題ありません。しかし、TomcatがContextのリロードをしてくれるのはあくまでも "/WEB-INF/classes" や "/WEB-INF/lib" の中が更新された場合であり、 "build/classes" 以下が更新されてもスルーしてしまい、Contextはリロードされません。
解決策として、以下のようにJava/Groovyクラスファイルの出力先を"src/main/webapp/WEB-INF/classes"に設定してしまいます。
build.gradle:
... sourceSets.main.output.classesDir = 'src/main/webapp/WEB-INF/classes' ...
これにより、"gradle classes"すると "src/main/webapp/WEB-INF/classes" 以下にクラスファイルを出力してくれますので、Tomcat側で変更を検出し、Contextをreloadしてくれます。
また、このままですと"gradle clean"した時に "src/main/webapp/WEB-INF/classes" を削除してくれませんので、"clean"タスクを以下のようにカスタマイズします。
clean { // add customized class output path to deletion targets of 'clean' task. delete << 'src/main/webapp/WEB-INF/classes' }
これにより、"gradle clean"すると "build/" 以下に加え、"/WEB-INF/classes" も削除してくれます(※ただし、上記cleanタスクのカスタマイズは、「ん~、こんな感じでイケんじゃね?」と試してみたらうまく行ってくれただけですので、もしかしたら厳密にはカスタマイズ方法勘違いしてるかもしれません。)
なお、あまりいじり過ぎたり何度もreloadが発生すると、Contextのreloadで以下のようなメッセージが表示されます。「怪しそうだな」と感じたら一旦Tomcatを停止して立ち上げ直すと良いのは、他のEclipseやIntelliJなどでの「サクサク開発」と同じです。
$ gradle tomcatRun :compileJava UP-TO-DATE :compileGroovy :processResources :classes :tomcatRun Started Tomcat Server The Server is running at http://localhost:8090/warsample1 (...) The web application [/warsample1] created a ThreadLocal with key of type \ [org.codehaus.groovy.reflection.ClassInfo.ThreadLocalMapHandler] \ (value [org.codehaus.groovy.reflection.ClassInfo$ThreadLocalMapHandler@64658ba0]) \ and a value of type [java.lang.ref.SoftReference] \ (value [java.lang.ref.SoftReference@46b1e8de]) \ but failed to remove it when the web application was stopped. \ Threads are going to be renewed over time to try and avoid a probable memory leak. (...)
また、これで "gradle war" したwarファイルの中を覗いてみると、以下のようにクラスファイルのエントリが重複してしまっています。
$ jar tf build/libs/warsample1-1.0.0.war ... WEB-INF/classes/net/glamenvseptzen/quickstart/ WEB-INF/classes/net/glamenvseptzen/quickstart/AdjustedGroovyServlet.class WEB-INF/classes/net/glamenvseptzen/quickstart/HelloServlet.class WEB-INF/classes/net/glamenvseptzen/quickstart/MyGroovyUtil.class WEB-INF/classes/net/glamenvseptzen/quickstart/MyStringUtil.class WEB-INF/classes/net/glamenvseptzen/quickstart/ToolKit.class WEB-INF/classes/net/glamenvseptzen/quickstart/AdjustedGroovyServlet.class WEB-INF/classes/net/glamenvseptzen/quickstart/HelloServlet.class WEB-INF/classes/net/glamenvseptzen/quickstart/MyGroovyUtil.class WEB-INF/classes/net/glamenvseptzen/quickstart/MyStringUtil.class WEB-INF/classes/net/glamenvseptzen/quickstart/ToolKit.class ...
ただし、展開すればちゃんと一つのみになっていますので、ひとまず心配はいりません。実際に単独でセットアップしたTomcatにdeployし、正常に動作することを動作確認しております。
Groovy/Gradle/Mixing Java and Groovy のテクニックを使ってます。以下のように、mainとtestの両方の "SourceSet" でJavaのソース指定を空っぽにして、Groovy側のコンパイラでコンパイルするように調整をしています。
build.gradle:
... [sourceSets.main, sourceSets.test].each { // compile java and groovy file at same time. it.groovy.srcDirs += it.java.srcDirs // disable java compilation it.java.srcDirs = [] } ...
GradleのJavaコンパイルのタスクも、Groovyコンパイルのタスクも、どちらも"Compile"タスクの型から派生しています。ということで、以下のようにすることでJava/Groovyの両方で共通してJavaソースのバージョン, 文字コード, デバッグ情報の埋め込みを設定できます。
tasks.withType(Compile) { sourceCompatibility = '1.7' targetCompatibility = '1.7' options.encoding = 'UTF-8' options.debug = true }
EclipseとGraldeの連携という観点で色々と挑戦されているようです。
今回、"tomcatRun"まではgradle-tomcat-pluginのおかげでスンナリ動いてくれましたが、Contextのリロードについて "/WEB-INF/classes" 「しか」見ないということに気づかず、数時間以上「おかしい・・・なんで "build/classes/..." 以下のファイルはちゃんと更新されてるのに、Tomcat側で反映してくれないんだ・・・」と悩んでました。
gradle-tomcat-pluginの過去のIssueなどを漁っているうちに、"tomcatGradleExample"を見つけて「あれ~??こっちはやっぱりちゃんとリロードしてくれる・・・どこが違うんだ・・・?」と見比べているうちに「あ、こっちは"/WEB-INF/classes"に出力するようにカスタマイズしてる。もしかして・・・」とTomcatのドキュメントとかソースまで手繰り寄せ、「やっぱり、"/WEB-INF/classes|lib"以下しか決め打ちで見てないんだ・・・」と確認でき、それでようやく、「じゃぁカスタマイズするか~。あ、でも、"tomcatGradleExample"って"gradle clean"しても"/WEB-INF/classes" 以下に残っちゃうよな・・・cleanタスクもカスタマイズが必要だ。」となり、それでようやくなんとか安定して動くようになった次第です。
あと、一応サンプルにはGradle添付のJettyプラグインも使えるようにしてます。ただ、こちらではContextの自動リロードをしてくれなかったのでスルーしてます。なんかGradle添付のJettyプラグイン、設定出来るパラメータも少ないし、gradle-tomcat-pluginと比べると大分見劣りがしてしまう・・・。
コメント