8u05参考までにindyを使わないGroovy独自機構による性能も見てみましょう。totalなんと、JDK7+indyにはダブルスコアで勝ってたのに、JDK8+indyに追い越されてしまいました。indy全盛時代の幕開けを感じますね。いうようなことを、Java-ja枠のTDDセッションを聞きながらまとめてみました。16:39Java8のInvokeDynamic実装一新によるGroovyのindyモードの性能改善効果が凄すぎた件listTweetもっと読むコメントを書く2014-04-17Gradleで特定のJarをtestRuntimeで使いたいけどWarからは除外したいgradleTwitterで@ruimoさんがつぶやかれていたので色々試してみた結果をまとめておきます。(試行錯誤で徐々に追記しています。辺が参考になりそうな気がします。(効かない)warタスクでもexcludesによるパターン除外が効けば良いんですけど、どうもできない感じですね...。パターン指定の仕方が悪いのかしら。Antパターン指定とかで試してみたんですが、何にも変化なしな感じ。warタスクで自前でフィルタリング結局「warに入らなくしたいだけ」なので、余計なruntimeなどをいじるのではなくwarに入れる処理のことろで自前フィルタリングするのが良さげです。自前でフィルタリングすると一応除外できた。使えないのですべての除外Jarを指定しなければならない。除外リスト内のパタンと部分一致に入っているものはnullにしておいて後でfindAllで除外する。null除外}どうでもいいけど、Groovyコレクション操作でfindAllの反対が欲しいなぁ。removeAllはJava標準APIに引きずられて破壊的なのが駄目な感じ。この方式でWarに入るJarは除外できます。これだと推移的依存関係は辿れなくて、ファイル名マッチングをするしかないので、すべての除外Jarを指定しなければならないのが面倒です。上記でfoofooが実はbarbarにも依存してたりすると、Warの中にbarbarだけが含まれてしまいます。(ただし、中途半端)で、ちょっとトリッキーだけど解決策としてこんなのを考えてみました。このように除外目的のconfigurationsを作ってしまうと楽な気がする。推移的依存関係を自動的に辿れるように除外用のconfigurationsを作ると便利。除外リスト内のパタンと部分一致に入っているものはnullにしておいて後でfindAllで除外する。null除外}こうすると、たとえfoofooが実はbarbarに依存していても、foofooの除外指定からたどられて除外対象に含まれるのでbarbarも除外できます。これもまだ半端な実装になっていて、Warに含めたいbazbazがbarbarに依存していると、foofooの推移的除外関係から単純にbarbarを除外しようとするので、Warの中にbarbarが含まれず、bazbazがまともに動かなくなってしまいます。その辺まじめに実装すればよいかもしれませんが、特定プロジェクトの都合で確実に除外指定したいブツが分かってるなら、案2あたりで止めておく方がよさげ。2つの依存構成を追加します。同じスコープを持ちます。構成が推移的に機能することは特筆すべき点です。warで不要なものをruntimeから除外してしまう。warには不要であるがruntime/testRuntimeで必要なJarをあらためてprovidedRuntimeで宣言しなおす。&#39;foo:foofoo:1.2&#39;}ruimoさんのユースケースだとこれで良いような気がしてます(動作確認してない)。(ボツ)だいぶシンプルになりましたが、除外設定とprovidedRuntime指定の2箇所でJarの情報が分散してるのがDRYではありませんね。そこは心配ありません。Groovyなのでこんな書き方ができます。して一元管理もできる。warで不要なものをruntimeから除外してしまう。warには不要であるがruntime/testRuntimeで必要なJarをあらためてprovidedRuntimeで宣言しなおす。21:00頃追記]providedRuntimeはテスト実行時(testRuntime)には入ってこないようです。考えたらテストで使えれば良いのだから直接testRuntime、コンパイル時も必要ならtestCompileに設定すればいいじゃないか、と気がつきました。testCompileにいれておけばtestRuntimeにも含まれます。いうことで、たぶんこれでFAな気がするんですがどうでしょうかね。して一元管理もできる。warで不要なものをruntimeから除外してしまう。warには不要であるがtestCompileで必要なJarをあらためて追加する。追記]案6は実は駄目ですね。うまく動いてると勘違いしたのはサンプルコードがまずかったです。依存先のsrc/mainのクラスとして何かに外部モジュールBに更に依存していて、そのBに対する制御をメイン側のPJでやるというサンプルじゃないと駄目なのでした。何が問題かというと、上の出力を見てわかるようにtestRuntimeに追加したはずの依存モジュールが入っていない(testRuntimeはtestCompileを引き継ぐので本来はtestCompileと同じだけの品揃えがあるべき)。実は、configurationsでごっそりruntimeからexcludeしてしまうと、メインPJのruntime系の依存性もすべてexcludeされてしまうのでした...。runtimeから除外してtestRuntimeに追加してるのに、excludeの評価が「runtime系全体」にかかるのはおそらく内部実装の都合上な印象を受けます。なっているものは仕方がない。依存先モジュール/プロジェクトごとに個別に推移的依存性をexcludeすればOKなので、こうやれば意図通りに動きました。して一元管理もできる。このプロジェクト自体のtestCompile/testRuntimeへの追加は意図通りに動作する。warには不要であるがtestCompile/testRuntimeで必要なJarをあらためて追加する。Opal氏の2案目をみて気づきましたが、依存モジュールごとの推移的依存先について選択的ではなくごっそりすべてexcludeして良いなら、これだけでOKです。warには不要であるがtestCompile/testRuntimeで必要なJarをあらためて追加する。&#39;org.apache.commons:commons-lang3:3.3.1&#39;}ぐるっと一周してすごくシンプルになりましたね。15:54Gradleで特定のJarをtestRuntimeで使いたいけどWarからは除外したいlistTweet広告を非表示にするもっと読むコメントを書く2014-04-08Groovy2.3.0-beta-1と噂のTraitを試してみたGroovy2.3.0-beta-1がリリースされましたね。目玉としてはやはりtraitでしょう。今までのMetaClassによるメソッドの動的探索パスをいじる系の機能で似たようなことはできましたが、何かと限界(複数スレッドにおける動作の保証とかかなり泥臭い感じだったり、一度動的メソッドを追加すると取り除くのが大変だったり)がありましたが、それらを超えるために静的ソリューションとしてtraitが実装されました*1。ドキュメントがすごくわかりやすくて、サンプルコードを上から順に読むだけで少なくともどのように使えるかは難なく理解できるでしょう。http://beta.groovy-lang.org/docs/groovy-2.3.0-SNAPSHOT/html/documentation/core-traits.html最初の方を読んでるとJava8のインタフェース+デフォルトメソッドと同じかな?と誤解しますが、Groovyのtraitはステートフルなのです。プロパティを定義して状態が持てる。完全に普通の多重継承です。それ以外は登場順の後勝ち」的なルールで明確に決定されますし、特定の実装を優先したい場合も簡単です。衝突が気になるような名前は避ければいいわけですし。詳しくはドキュメントのこの辺を読みましょう。GroovyConsoleで軽く試してみましたが、非常にいい感じです。gist10127510いわゆるアカデミックな本家の"trait"や、"Scalaのtrait"とどの辺が違うのかあたりは気になるところです。2014/4/9追記ASTはこんな感じ。細かい点はおいといてなるほどねーな感じです。2013の15日目として書かれたものです。@grimroseさんでした。最近某自作GrailsアプリにてGrails上でVert.xを利用してWebSocketのプッシュを実装したりしてたので、今回はその話を書こうかなと思っていたのですがやっぱりやめて、以前からそのうち書こうと思って寝かせていた開発Tipsネタの方がちょうど良い感じに熟してきたのでそちらを紹介することにします。Grailsによる通知からのテストレポート表示(前回までのあらすじ)以前、Grailsのアプリ起動完了やテストの結果をGrowlで通知するEvents.groovyが便利な件という記事を書きました。Grailsのビルドイベントを、Grailsのイベント機構を利用して拾って、Growlで通知するというものです。通知するだけではなくて、その通知ペインをクリックすると、そのテストレポートがブラウザで表示されるので、ユニットテストが結構捗ります。LionでOS標準の通知機構ができたので、それを利用した方法もこちらで紹介されています。自分も今はこれをベースに使っています。OS標準のNotificationに通知するためのコマンドがあるので、growlnotifyコマンドの代わりにそれを使う感じです。openオプションを使うことで通知ペインのクリック時にURLを表示させることができます。openオプションにテストレポートHTMLファイルのURLfile://.../index.htmlを指定することで、クリック時のブラウザ連携を実現することができるわけです。他にもexecuteオプションで任意のコマンドを実行させたりもできます。詳しくは↓あたりをどうぞ。Lionの通知センターへ通知を表示させる『terminal-notifier』http://veadardiary.blog29.fc2.com/blog-entry-4018.htmlGradleによる通知からのテストレポート表示さて、GradleもGrailsとは違う方式ながら、イベントリスナ機構を持っています。Buildhttp://mrhaki.blogspot.jp/2012/10/gradle-goodness-getting-announcements.htmlGradle標準(?)の実験的プラグインで通知アプリへの連携方法が提供されていて、それを使ってビルドイベントの前後で通知する方法がMr.Hakiのブログでまとめられています。自分の場合は、取り回し重視で以下のシンプルなコードを改造して、直接terminal-notifierコマンドを実行するようにして使っています。Notificationshttps://gist.github.com/cybo42/1030021サンプルコードは最後にまとめて紹介するとして、先を急ぎます。Alfredとは?http://www.alfredapp.com/ここで突然ですが、AlfredというMac用のコマンドライン型ランチャがあります。ホットキーで表示される入力ペインにアプリケーション名を入力すると、インクリメンタルサーチで候補が絞り込まれていき、対象が見つかったところで選択してENTERで実行します。QuickSilverも有名ですが、自分はAlfredを愛用しています。Searches)」を独自定義すればシームレスに色々な情報にたどり着く基盤を築くことができます。さっきのテストレポートをみたいんだけど...さて、さきほど紹介したGrails/Gradleの通知→レポート表示の場合、通知が表示されている間にクリックしないとレポートにたどり着けません。履歴を表示してクリックすることもできますが一手間増えますし、だからといって、Stickyに通知が残るようにすると逆にウザいことが多いのでいやな感じです。通知からしばらくたって、コードを修正している最中にテストレポートを再確認したくなることもあります。「さっきのテストレポートがみたいなぁ」と思うわけです。みなさんは、IDEでコードを書いていて「あのソースファイルを修正しよう」と思ったときどうやってそのファイルを開いていますか?まさかエクスプローラ風のビューアからディレクトリ階層をたどってファイルを見つけてダブルクリックしてないですよね?EclipseでもIntelliJでも、リソース名/型名によるインクリメンタルサーチでファイルを開く機能があります。「あのソースファイル」と思った時点でその名前が念頭にあるんですから、それを使って対象を開くのがもっとも頭にも手にもやさしい自然な方法な訳です。VimmerならUniteプラグインの出番ですね。テストレポートの表示も同じです。頭では「さっきのテストレポートがみたいなぁ」と思っています。その欲求をできるだけストレートにアクションに結びつけるにはどうしたらよいか。ここでAlfred(または類似のランチャ)が役立つわけです。Alfredで開けないかな?というごく自然な流れですね。Alfredで「さっきのテストレポート」を表示するにはAlfredのカスタム検索を使って、これを実現しましょう。彼はGrails/Gradleの文脈なんて知らないので、「さっきのテストレポート」をAlfredに見つけさせるのは難しいです。そこで、通知と同じようにビルドイベントのフックで仕込みをしてしまうことにしましょう。ビルド実行後のフックで「テストレポートのファイルURI」を固定パスの隠しファイルに書き込んでおく1.で書き込んだ固定パスのファイルを開くようなカスタム検索をAlfredに定義するこれだけです。単純な戦略ですがこれで十分です。あとは、Grailsの場合なら「さっき起動したアプリのホーム画面」もさくっと表示できると捗りますね。いうわけで、早速やってみましょう。実際のコードサンプルGrails以下のコードを~/.grails/scripts/_Events.groovyとして保存します。Gradle以下のコードを~/.gradle/init.gradleとして保存します。Alfred以下の文字列をコピーして、Alfredの入力欄に貼り付けるだけでカスタム検索が登録できます。ユーザのホームディレクトリを使うので、以下の__YOUR_ACCOUNT__の部分を自分のアカウント名に書き換えてから、Alfredの入力欄に貼り付けてください。AlfredからのGradleテストレポート表示alfredapp://customsearch/Gradle%20Open%20Latest%20Test-Report/gradletestreport/ascii/url=file:///Users/__YOUR_ACCOUNT__/.gradle/latestTestReport.htmlAlfredからのGrailsテストレポート表示alfredapp://customsearch/Grails%20Open%20Latest%20Test-Report/grailstestreport/ascii/url=file:///Users/__YOUR_ACCOUNT__/.grails/latestTestReport.htmlAlfredからのGrailsローカル起動アプリのホーム画面表示alfredapp://customsearch/Grails%20Open%20Latest%20Run-App/grailsrunapp/ascii/url=file:///Users/__YOUR_ACCOUNT__/.grails/latestRunApp.htmlこれでOKです。icon"ゾーンにドラッグ&ドロップすれば、更に見た目がクールになります。Gradleのロゴアイコンhttps://github.com/gradle/gradle/tree/master/subprojects/distributions/src/toplevel/mediaGrailsのロゴアイコンhttps://github.com/grails/grails-core/tree/master/media/icons試してみるまずはGradleプロジェクトをビルドしてテストも実行しましょう。無事に以下のような通知が表示されたでしょうか?表示されていれば裏できっと「さっきのテストレポート」情報も記録されているはず。Test-Report」を選択すると、期待通りブラウザ上にテストレポートが表示されましたね。Grailsプロジェクトがある人はそっちも是非ためしてみてください。Run-App」おわりに他のOSやコマンドラインランチャでもこの方法が使えます。Mac/Alfred使い以外の人も是非お試しを。Blog|ブログを報告する。