マキノ式ブログ

2.0.1の時とか確かできなかったのであきらめてたんだけど・・・。

いつの間にかできてる、そういえば最近surefireではかれるのテキストレポートの文字化けが直っていたような気が・・・・・、あれ？いつからだっけか・・・・

とりあえず組み合わせは
Maven 2.0.4
surefire-report-maven-plugin 2.0-beta-1
→2.0-beta-2-SNAPSHOTがあるけど別にこれ使わなくでも問題ないみたいです。

あとmaven-site-pluginのコンフィギュレーションでoutputEncodingにUTF-8を指定すれば良いです。（どーでもよいけど、コンフィギュレーションのところにDiscoveredとか書いてあるのはなぜでしょうかｗ）
http://maven.apache.org/plugins/maven-site-plugin/site-mojo.html

下記がレポーティングの設定例です。
　<reporting>
　　<plugins>
　　　<plugin>
　　　　<groupId>org.apache.maven.plugins</groupId>
　　　　<artifactId>maven-site-plugin</artifactId>
　　　　<configuration>
　　　　　<outputEncoding>UTF-8</outputEncoding>
　　　　</configuration>
　　　</plugin>
　　　<plugin>
　　　　<groupId>org.codehaus.mojo</groupId>
　　　　<artifactId>surefire-report-maven-plugin</artifactId>
　　　　<version>2.0-beta-1</version>
　　　</plugin>
　　</plugins>
　</reporting>

サイトビルド自体の日本語化は下記にドキュメントあります。
http://maven.apache.org/plugins/maven-site-plugin/i18n.html
なにやら、自分でソース落として、↑のサイトのリソースを配置してmvn installすればよいよーとあります。
→ 中国語のリソースファイルが欲しいなｗ誰かに作ってもらおうかしらん

あと、mvn siteでもTestがこけると中断する問題に関しては、私の場合は下記のようにprofilesで回避してます。
surefireプラグインの設定
　<plugin>
　　<groupId>org.apache.maven.plugins</groupId>
　　<artifactId>maven-surefire-plugin</artifactId>
　　<configuration>
　　　<testFailureIgnore>${test.testFailureIgnore}</testFailureIgnore>
　　</configuration>
　</plugin>

プロファイルの設定
　<profiles>
　　<!-- For Site Build Profile -->
　　<profile>
　　　<id>site</id>
　　　<properties>
　　　　<test.testFailureIgnore>true</test.testFailureIgnore>
　　　</properties>
　　</profile>
　</profiles>
で、
　mvn site -Psite
みたいな感じです。

#同じくmavenのcargoが0.1から0.2にあがってる。でもなぜか0.1の設定だと失敗、SNAPSHOTで利用して他のが仇に・・・・、ある日突然デプロイ失敗ｗこちらも、早々に調べたいです。

最近中国のコンシューマ系の案件に携わって、感じたのです。
『マジで完全なコンシューマ系サイトにはJavaは向いてないかも・・・orz』

何を今更と思われる御人も多いかと思います。なにせ昨今の世の中Rails旋風が吹きまくって、PHPによるラピッドなサイトビルドが花盛りです。
Javaなんて黙ってWASでXAトランザクションとか言ってればいんじゃない？・・・ねえ？（いやぁーー、そんなこと言わないで！泣いちゃう、泣いちゃうから！！）

確かに、
コンシューマ系のサイトにおいて今さら超重量級フレームワークStutsやJSPはあり得ないと思います。それに極端な話、客にとってはJSPが2.0だろうが、DIコンテナやO/Rマッピングを用いてようが興味ないわけです。
そこで、Javaがコンシューマ系サイト構築に向いていない（と感じる）理由を考えてみました。
　１、少なくともServletコンテナが必要（つまりTomcatとかJettyのこと）
　２、WARのデプロイが必要
　３、1画面作るまでのステップが多い
　４、静的言語のため冗長なコードが多い
　５、開発者がシステム開発的手法を持ち込みすぎ
ほかにもいろいろありますが、代表的なのはこんなもんだと思います。最初のServletコンテナが必要というのは基本的にはどう転んでもどうにもなりません。許してください・・・・
２、３、４、５はつまり書いたらすぐに結果が見れないことによるロスが大きいということです。

つまり、
簡単に言うと
　その場で修正してその場で確認させてよ。
　デプロイとかさせんなよ。
　とにかくごちゃごちゃ言うなよ。
・・・・というところでしょうか？ある意味むちゃです。
JAVAによるWEB開発というのは非常に手順が多く動かすまでに手間と時間がかかります。そして、一方でJava開発者も面倒に感じながらも、その手法を好んでいる傾向があります。少なくとも私は好きです。

でもね、
この思想はスピードが要求されるラピッドな構築では残念ながら通用しないわけです。いくら気取っていても、一昔前ならJavaでも良かった案件がPHPに取って代わられつつあります。PHPの開発者がなんと言おうとPHPはバルクでラピッドな開発に多用されており、そこへJavaが入り込めません。

さらに、
上海に来てから、こちらのエンジニアが行う欲望に忠実な場当たり的開発を見せつけられて、自分の開発手法が硬直化していたことを強く感じました。彼らの手法が良いか悪いかは別として、軍服に体のサイズを合わせさせるわけにはいかないわけです。

そこで、
そんな現状に対する解答として、遅ればせながらRuby on Railsのドグマがぴったりだと思いました。特に二つめには衝撃を受けました。（遅すぎｗ
　・Less software（より小さいソフトウェア）
　・Convention over configuration（慣習は設定を超える）



そんなわけで、
しばらくの間、まじめにRuby on Railsから始めて、Groovyを中心としたソリューションを学んでみることにしました。
GroovletsとGroovyTemplates、もしくはVelocityを組み合わせればラピッドな開発が可能なはずです。

またGroovyは静的なJavaクラス群も利用可能であるわけで通常のシステム開発にも応用できそうです。（いわゆるグルーコードによりクラスを関連づけるということ）