PHPまみれの毎日ですが、意外なところでRubyやnode.jsが使われていたりHaskell使おうみたいな話もあったりと、環境やアーキテクチャによって様々な言語が使われているようです。
Java大好き人間としてはJavaでなんかやったるしかないだろう、ということで個人的な実験ですがJavaで実装されたPHPの実行環境Quercusを使ってみたところ、あまりにハイパフォーマンスでビビったので皆様にご紹介です。

Quercusってなんぞ

Quercus(くえるかす)はRasinというアプリケーションサーバーでお馴染みのCauchoが開発したPHPの実行環境です。ライセンスはGPL。
warとして配布されているのでTomcatを始めとしたRasin以外のアプリケーションサーバーでも動きます。商用のRasin ProfessionalではPHPスクリプトをコンパイルすることができ、更にパフォーマンスをあげることができるそうです。

互換性が心配になりますが、公式にMediaWikiやWordpressといったアプリケーションの動作が確認されているので、そうそう変な書き方しなければ大体のアプリケーションは動くのではないでしょうか。

AWSのセットアップ

AWSのマイクロインスタンスにyumでphp/httpd/tomcat7あたりをインストールして比較しました。
セキュリティグループの設定で80と8080のポートを開けておきます。

yum update -y
yum install -y php php-pear tomcat7
pear channel-discover pear.ethna.jp
pear install -a ethna/ethna-beta

cd /var/www/html
ethna add-project sandbox
cd /usr/share/tomcat7/webapps
wget http://caucho.com/download/quercus-4.0.25.war
service tomcat7 start
cd quercus-4.0.25
cp -Rp /var/www/html/sandbox ./quercus-4.0.25

service httpd start

これで、

http://なんとかかんとか.amazonaws.com/sandbox/www/

http://なんとかかんとか.amazonaws.com:8080/quercus-4.0.25/sandbox/www/

のようなURLでそれぞれアクセスできるようになります。

JMeterで計測

JMeterでベンチマークとってみました。ベンチマークの取り方に詳しくないので「こうやると正確だよ！」「こういう比較するといいよ！」ってのがあれば教えてください＞＜

とりあえずスレッド数10、Ramp-Up期間1秒、ループ回数100でそれぞれ試してみました。すると、

• httpd 24.0[requests/src]
• Quercus 87.0[requests/sec]

こんな結果に・・・！Quercusさんパネェっす！

とは言えインストールしたままのPHPなんてフツーは使わんですよね、せめてAPCでも入れてみましょう。

yum install php-pecl-apc
service httpd restart

再び計測。

• httpd(APC) 59.7[requests/sec]

うーむ、やはりQuercusのが早い。

所感

とまあどちらもチューニングせずの、ブログに書くには雑すぎるベンチマークでしたが、Quercusのポテンシャルの高さを少しは感じられたかと思います。PHP/httpdのチューニング、Java/Tomcatのチューニングをちゃんと施してのベンチマークも取ってみたいですね。nginx/FastCGIの組み合わせはまだまだパフォーマンス出るでしょうし、Tomcat以外のアプリケーションサーバーも実験の価値ありですね。

とは言えQuercusを使うということは単なる高速化だけではなく、JVM上で動いているということを忘れてはいけません。JavaOne Tokyoで感じた方も多いと思いますがOracleのJavaへの本気度はマジでしょう、まだまだJavaはメインストリームを突っ走るはず。

過去のJavaの資産が活用できるのはもちろんのこと、JDBCコネクションプールや、Fork/Joinを始めとしたマルチコア/マルチプロセッサ対応、JavaEE7のマルチテナント、クラウド化や各種アプリケーションサーバーの強力な負荷分散・フェイルオーバーの恩恵を受けられることは運用の面でも大きなアドバンテージになるのではないでしょうか。

意外とサクっと試せるので、興味がある方はぜひ試してみてください。

抱負というかスタンスについて簡単に綴ってみます。

「イカしたソシャゲーをデベロップしてギロッポンでチャンネーとシースー！」

・・・とかいったマインドではもちろんなく、どちらかというと

大規模なコンシューマーサービスのインフラをどう活かすか

といった下回りへの強い関心と

優秀なエンジニアの渦に揉まれて自身の価値を磨く

といった以前のエントリで述べた点で決めました。

選考過程では大規模インフラを扱う会社や、優秀なエンジニアが数多くいる会社は他にもいくつかありましたが、そのなかでグリーを選んだ理由は、会社の雰囲気・空気感が合いそうだというところが大きいです。

面接に行った他の会社の中には、フロア全体や面接していただいたエンジニアの方から、なんか、こう、悲壮感漂っていたり、疲れを伴うだらしない空気感があったりと、直感的に「ここは合わないぞ」感が伝わるところもありました。

雰囲気・空気感の感じ方は人それぞれだとは思うのですが、そういった点でグリーは単純に「あ、いいかも」感がしたのが大きいです。人に説明する説得力はゼロだけれど、自分の直感は大事。

Javaエンジニアとグリー

グリーはPHPがメインストリームの会社なので、Javaエンジニアとして10年近く培ってきたスキルを捨てるように思えるかもしれませんが、分散処理、機械学習、検索エンジンなどの所謂ビッグデータ系のフレームワークはJavaで実装されていることが多く、Javaがメインストリームでない企業においても今までのスキルも少しは役に立つシーンもあるんじゃないかなあ。

とは言え、よく言われることですが言語なんてたかが道具なので、ぶっちゃけなんでもいいんです。そしてデキるエンジニアはなんの言語を使おうが成果は出せるもんだと思うので、私もそういったエンジニアになれるようこれまでの経験を生かして頑張らねば！弘法筆を選ばず、ってやつですね。

脅しと決意

中の人や知り合いには「グリーのインフラは優秀だよ」「インフラの人たちはキレ者多いから楽しいですよー」といった脅し文句をかけられてビクビクしておりますが、ドM魂を燃やしつつ荒波に揉まれエンジニアとしてのプレゼンスを高め、いち早く価値を提供できるよう精進します。

転職するにあたり色々な会社を見ていくうちにいままで見えていなかったGxPという会社が見えてきて結構いい会社だよなあ、と改めて感じたので思い出がてら簡単にご紹介します。結論から言うと

今風にSIやりたいならGxP一択しかないよ！

ということです。

JavaでエンタープライズなSI会社です

「時代はGUNDAM、Java(笑)はオワコン」とか言う人もいてJavaでSIやってる会社というと不安を感じる人もいるようですが、実際なかで働いたり勉強会参加したりOracleのJavaへの関わり方を見ると、なんだかんだ言ってまだまだメインストリームで在り続けるだろうなと思います。

どちらかというと日本でのJavaオワコン感って、言語仕様云々ではなく一山いくらで売られているエンジニアのスキル不足や時代遅れなフレームワーク・開発手法に起因しているような気がする。そりゃ未だにJava1.4やStruts2使ってる上にイケてない社内ORMを強要されてるようじゃそう感じるよなあ。

OSSプロダクトは積極採用

そしてGxPはエンタープライズ向けSIの割にOSSのプロダクトをエンジニアの提案で積極的に採用できるのが楽しい。Wicket + Hibernate EntityManager + Guiceなんてプロダクトもあるし、Luceneでごっつり全文検索やったり、RESTのAPI作る、ってんならJAX-RSの実装いろいろ弄ってから決められる。Hadoop使おうとしている人もいたりGroovy使ってるプロジェクトもあったなー、Scala使いたい！とかもやり方間違えなければ全然通ると思う。新しい開発手法やフレームワークが好きな人はマジオススメ。日々勉強です。

社長こだわりの椅子

そしてGxPは椅子がいい！これもっと対外的にアピールすればいいのに(笑)

コンテッサ(Contessa) チェアー ポリッシュフレーム 座メッシュ 【スタンダード】 ブラック CM31AB-FBH1

渡邉社長のこだわりで社員の椅子は全員オカムラのコンテッサです。腰が全然痛くならないし、リクライニングすると昼寝にもってこいだし、メッシュなので夏でも蒸れないし、椅子の上であぐらかいてストレッチできるし、いいことだらけです。

以前働いていた会社は中古で3000円くらいかってくらい粗悪な椅子で、腰の痛みと戦う日々だったのだけれど、その頃と比べると天と地の差。心地良くコーディングができます。

ブラック企業という都市伝説

SI＝残業だらけで有給使えず＝ブラック企業、といったイメージが付きまといますが、私は残業なにそれ？状態で毎日10:00〜19:00で定時退社していました。もちろん仕事の進め方など人それぞれだとは思いますが。

確かにリリース直前に不具合発見したりサーバーがダウンした時はそれなりに残業(そして徹夜)しましたが、4年務めていてもそんな事あったのは片手で数えられる程度。

もちろん有給もちゃんと使えます。私は趣味のパフォーマンス活動の関係上、平日のイベント仕事がある日はもちろんのこと、2週間に及ぶ公演期間中まるっと休めたりとかなり融通ききます。なんだかんだで有給消化率100％でした。

とは言えまだまだ発展途上

テストや開発手法など模索している最中でもあり、プロジェクトごとに品質がまちまちになってしまうことは確かにあります。ただ、この「発展途上」という状態をプラスに捉えるか、マイナスに捉えるかによってGxPの楽しみ方は大きく変わってきます。整備されたフレームワーク・開発手法などを徹底的に効率良く使うことに長けている人よりも、自分で試行錯誤して創り上げることにエクスタシーを感じられる人がGxPという会社を楽しめると思います。

そして転職へ

さて、仕事の内容には不満もなくワークライフバランスもとれているのに、なんで転職するの？と気になるところだと思いますが、なんというか過酷な環境に自分を放り込んでみたいなと思ったことが大きいです。

刺激がない会社という訳ではないし、デブサミではお馴染みの@yusuke_arclampやDDD、継続的デリバリーなどの翻訳を手掛ける@digitalsoul0124といったSIや開発手法を真剣に考え続けている優秀な人たちと一緒に仕事することは学べることも多く、大きな成長につながります。ただ私自身、年齢的にもまだまだギラギラした荒波に揉まれて必死こかなきゃついてけないという危機感をもって仕事をすることが、自分自身の成長につながるとの思いから今回転職を決意しました。とんだドMですね。

渡邉社長には「エンジニアとパフォーマー、どっちが本職かわからん」と心配されながらも「SIやりたくなったら戻っておいで」と言っていただくなど暖かく存分に甘やかされながらの4年間でした。

そんな良い人に恵まれているGxPという会社ですが、このタイミングでメンバー増員計画中なので、ちょっとでも興味ある方がいらしたらご紹介できます。Twitterやfacebookやメールで連絡いただければと。

転職についてのエントリはまた後日改めて。

 やはりMaven

すいません、やっぱり今日もMavenネタです。仕組みとしてはwar生成時にリソースとしてsiteをまるっと突っ込むだけです。

<plugin>
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-war-plugin</artifactId>
        <version>2.1.1</version>
        <configuration>
                <webResources>
                        <resource>
                                <targetPath>site</targetPath>
                                <directory>${project.build.directory}/site</directory>
                        </resource>
                </webResources>
        </configuration>
</plugin>

targetPathは生成先のディレクトリ名です。上記の場合http://localhost:8080/hogehoge/site といったURLでアクセスできるようになります。targetPathを書かなければhttp://localhost:8080/hogehoge/ でアクセスできます。

<plugin>
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-site-plugin</artifactId>
        <version>3.0</version>
        <executions>
                <execution>
                        <id>attach-site</id>
                        <phase>prepare-package</phase>
                        <goals>
                                <goal>site</goal>
                        </goals>
                </execution>
        </executions>
</plugin>

あとはprepare-packageでサイト生成するだけです。簡単ですねー。

何の役にも立たないかもしれませんがどうぞ！

転職エージェントもなかなかいい

エージェントは特にこだわりもなく、なんとなくリクルートエージェント。担当はWeb関連企業専門の森本冴子さん。とても頼りになる気さくな美人さんでした。

予めキャリアシートを埋めておき、エージェントと面談では自分が興味のあった企業や、キャリアビジョンなどを話していくと「でしたら、この企業とか結構興味あったりしませんか？」とナイスなサジェストをしてくれます。「うおお、なにこの会社！面白そう！」みたいのが結構あります。自分で探すよりポンポン出てきてやっぱさすが本職だなあ、と感じました。

紹介も単に企業の資料を見せてくれるだけではなく、実際にエージェントが企業の人事の方と話した感触や、訪問した際の会社の雰囲気(良い面も、悪い面も)も交えて紹介してくれるので、思っていた以上に情報収集が進みます。

日程調整丸投げ

選考が複数件進んでいると各会社のブッキングが面倒なのは想像に難くないと思うのですが、例えば

10日から13日の20:00以降、もしくは14日と15日どちらかの19：30以降なら空いてるのでその中で調整してください。

とお願いするとあっという間に各会社と調整してブッキングしてくれるのは本当に楽チンでした。すごい、秘書みたい。

年収交渉とか

企業の採用ページや求人情報サイトに「想定年収400〜1200万」とか「モデル年収 27歳、入社2年目 年収700万」とか書かれてても、ぶっちゃけほとんど参考にならんと思うのですよ。

またエントリー時や面接の際に、低すぎる希望年収を提示して足元見られたり、高すぎる希望年収で人事の心象悪くしたり(無いとは思うけどｗ)するのではないかとモヤモヤするポイントではないでしょうか。

そういった点をエージェントに相談できるのは心強かったです。キャリアや実績を考慮して「この企業でこの年収は難しいと思いますよ」とか「以前この企業にはこういったキャリアの方がこれくらいの年収で転職されました」みたいな生々しい情報を惜しげもなく教えてくれるので、企業ごとの年収感は比較的高い精度で検討できると思います。

 ソーシャル転職はプッシュ型、エージェント転職はプル型

ソーシャル転職は「この人と一緒に働けたらいいな」とか「現場で働いている生の声を聞きたい」といったプッシュ型、逆にエージェント転職は「こういった面白いことやれる会社はないか」とか「この条件にあった会社ってない？」といったプル型の転職の形だと思います。

どちらも一長一短あるとは思いますが、エージェントが提案した企業に勉強会で知り合った人が勤めていないかチェックして、TwitterやFacebookで現場の声を聞いたりすると、より正確に企業のことが見えてくるのでオススメです。組み合わせ大事。

エージェントを使って大局観を持ちつつ、ソーシャルメディアを使って現場の声を聞き、エージェント経由で各種手続きをしてもらう、なんてのが今風かもしれません。

なんかめっちゃ転職エージェントの回し者みたいな記事になっちゃいましたが、ステマとかじゃないですよ(笑) なにかの参考になれば！

「えーっ、手動デプロイが許されるのは小学生までだよねー(笑)」

とディスられること間違いなしです。

継続的デリバリーを行うのであればCIサーバーからボタン1つでデプロイしたいですよね。今回はその方法をご紹介します。

Mavenで使う

方法はやっぱり我等がMavenです。幸いなことにBeanstalk Maven Pluginという どストライクなプラグインがあります。

<;plugin>;
	<;groupId>;br.com.ingenieux<;/groupId>;
	<;artifactId>;beanstalk-maven-plugin<;/artifactId>;
	<;version>;0.2.5<;/version>;
<;/plugin>;

セントラルリポジトリにあるので、プラグインリポジトリの設定は必要なく上記の記述だけでOKです。

これをMavenのリリース時にBeanstalkにデプロイするには、

<;plugin>;
	<;groupId>;org.apache.maven.plugins<;/groupId>;
	<;artifactId>;maven-release-plugin<;/artifactId>;
	<;version>;2.2.2<;/version>;
	<;configuration>;
		<;goals>;package beanstalk:upload-source-bundle beanstalk:create-application-version beanstalk:update-environment<;/goals>;
	<;/configuration>;
<;/plugin>;

のようにmaven-release-pluginのgoalsにbeanstalk-maven-pluginのゴールを記述してやります。

Beanstalkのバージョンラベルは${beanstalk.versionLabel}が使われます。デフォルトは${maven.build.timestamp}となっていますが、maven-release-pluginと組み合わせる場合、pomのバージョンと合わせるのが良いと思います。propertiesで

<;beanstalk.versionLabel>;${project.version}<;/beanstalk.versionLabel>;

としてやりましょう。

Beanstalkの初期設定

初期設定といっても簡単で、AWS Management Consoleからポチポチとサンプルアプリケーションをデプロイしましょう。Application Nameは${project.artifactId}に合わせておきます。

S3の設定

warはAWS S3にアップロードされるので、ターゲットとなるバケットを作成しておきます。デフォルトでは${project.artifactId}のバケットにアップロードされます。

AWSアカウントの設定

BeanstalkにデプロイするためのAWSアカウントをsettings.xmlに記述します。https://aws-portal.amazon.com/gp/aws/securityCredentialsもしくはAWS IAMよりアクセスキーIDとシークレットアクセスキーを取得してください。

AWS IAMでのパーミッション

AWS IAMで作成したユーザーのアクセスキーIDとシークレットアクセスキーを使う場合、パーミッションはAWS Elastic Beanstalk Full Accessを選択してください。シークレットアクセスキーは作成直後しか見ることができない？ようなので忘れずにメモしておきましょう。忘れてしまった場合は、ユーザーのSecurity Credentialsタブより作成し直すことができます。

settings.xmlに記述

usernameにアクセスキーID、パスワードにシークレットアクセスキーを記述します。以前のエントリで紹介した方法でパスワードは暗号化しておくとよいでしょう。

<;servers>;
	<;server>;
		<;id>;aws.amazon.com<;/id>;
		<;username>;AKIAID2HPK4GWMGQ4JWA<;/username>;
		<;password>;{x3vArRlg3GxSApoHlXNOOG1llbg4aB2Uj8JuEM34An1bN71SOsSdSw5PJq9M/aszy9bvdK+fyxKZ3DHq+TFWLg==}<;/password>;
	<;/server>;
<;/servers>;

こんな感じ。

デプロイしてみる

あとは普通に

mvn clean release:prepare release:perform -B

とすればリリースと同時にBeanstalkへのデプロイも行われます。便利！

https://github.com/nagaseyasuhito/bouvardiaが上記設定をしたプロジェクトなので参考にどうぞ！

ということで先ほどリリースされたロケタッチの住所正規化APIをJerseyで遊んでみました。

Jersey ClientとJAXBでJSONを読む

Jerseyはリクエストの結果やPOSTデータがXMLやJSONの場合、JAXBの仕組みを使って良きようにPOJOにバインドしてくれます。住所正規化APIのJSONは素直なフォーマットで提供されているので、以下のような簡単なPOJOでOKです。

@XmlRootElement(name = "address_normalize")
public class AddressNormalize {
	public static class Result {
		public static class Normalize {
			@XmlElement
			private String region;

			@XmlElement
			private String number;

			@XmlElement
			private String build;
		}

		@XmlElement
		private String zip;

		@XmlElement(name = "region_id")
		private String regionId;

		@XmlElement
		private String address;

		@XmlElement
		private Normalize normalize;
	}

	@XmlElement
	private Integer code;

	@XmlElement(name = "is_error")
	private Boolean error;

	@XmlElement
	private String query;

	@XmlElement
	private Result result;
}

getter/setterは省略してあります。privateではなくpublicにして直接フィールドを操作するでもいいと思います、お好みでどうぞ。

実際のコードはこんな感じです。

Client client = Client.create();
WebResource webResource = client.resource("https://api.loctouch.com/v1/geo/address_normalize");

AddressNormalize result = webResource.queryParam("address", "東京都新宿区新宿5丁目17番17号 渡菱ビル3階").get(AddressNormalize.class);
assertThat(result.getResult().getAddress(), is("東京都新宿区新宿5-17-17 渡菱ビル3階"));

簡単ですねー。GitHubにコードをpushしておいたので遊んでみてください。

https://github.com/nagaseyasuhito/sandbox-loctouch

バイナリは一度だけビルドする

というものがあります。

継続的デリバリー 信頼できるソフトウェアリリースのためのビルド・テスト・デプロイメントの自動化

テストがちゃんと通ったバイナリをそのまま本番環境にリリースしましょうね、というプラクティスです。たぶん。 このプラクティスを実践しようとすると、Mavenで環境ごとのプロファイル切り替えてビルドするのはNGということになります。よくあるのがデータベースへの接続情報ですね。今まではこのように書いていました。

<profile>
	<id>development</id>
	<activation>
		<activeByDefault>true</activeByDefault>
	</activation>

	<properties>
		<javax.persistence.jdbc.driver>org.h2.Driver</javax.persistence.jdbc.driver>
		<javax.persistence.jdbc.url>jdbc:h2:mem:development</javax.persistence.jdbc.url>
		<javax.persistence.jdbc.user />
		<javax.persistence.jdbc.password />
	</properties>
</profile>
<profile>
	<id>production</id>
	<properties>
		<!-- productionではテストをスキップする -->
		<maven.test.skip>true</maven.test.skip>

		<javax.persistence.jdbc.driver>com.mysql.jdbc.Driver</javax.persistence.jdbc.driver>
		<javax.persistence.jdbc.url>jdbc:mysql://localhost/production</javax.persistence.jdbc.url>
		<javax.persistence.jdbc.user />
		<javax.persistence.jdbc.password />
	</properties>
</profile>

リリース用プロファイル(production)はmaven.test.skipをtrueにして本番のデータベースでテストを動かさないようにしています。 これらの情報をバイナリの外に出すにはどうしたらよいでしょうか？前置きが長くなりましたが、今回はJavaでお馴染みのJNDIを使って解決する方法をご紹介します。

テスト環境でどうやってJNDI使うの？

さて、GlassfishやTomcatなどのアプリケーションサーバー上であればJNDIを使うのも簡単なのですが、JenkinsなどでテストでJNDIを使うにはどうしたらよいでしょうか。

Spring FrameworkにはApache Geronimoの成果物であるApache XBeanを使うことでJNDIを提供できるのですが、Spring Frameworkを使わないプロジェクトの場合はなかなか難しいかと思います。

そこで、オンメモリで動くシンプルなJNDIコンテナ実装、その名もsimple-jndiを使った方法をご紹介します。

simple-jndi

Mavenのセントラルリポジトリにデプロイされているので、以下のdependencyを追加してください。

<dependency>
	<groupId>simple-jndi</groupId>
	<artifactId>simple-jndi</artifactId>
	<version>0.11.4.1</version>
	<scope>test</scope>
</dependency>

scopeをtestにしておくことで、リリースビルドには含まれないようにします。

次にsrc/test/resourcesにjndi.propertiesを追加し、simple-jndiを使うように設定します。

java.naming.factory.initial=org.osjava.sj.SimpleContextFactory
org.osjava.sj.root=file://src/test/resources

java.naming.factory.initialにはsimple-jndiのjavax.naming.spi.InitialContextFactory実装、org.osjava.sj.rootはsimple-jndiが参照する設定ファイルのルートディレクトリです。サンプルを見たらclasspathスキームを使えるような事が書いてあったのに、実装をみたらfileスキームしか使えなかった・・・！commons-vfsあたりで様々なスキーム使えるようにしてコントリビュートしたいかも。

さて、試しにjavax.sql.DataSourceの設定を記述してみます。

type=javax.sql.DataSource
url=jdbc:h2:mem:development;DB_CLOSE_DELAY=-1
driver=org.h2.Driver
user=
password=

データベースにはh2databaseを使っています。上記のテキストをsrc/test/resources/datasource.propertiesとして保存しましょう。

設定はこれだけです。上記の場合datasourceという名前でjavax.sql.DataSourceがlookupできます。簡単ですね！

https://github.com/nagaseyasuhito/fatsia

にsimple-jndiを使ったテストを書いてあるので、参考にしてみてください。

settings.xmlに直接ユーザー名とパスワードを保存する方法もあるのですが、リポジトリの設定などをsettings.xmlで共有する可能性も考えると直接記述するのはセキュリティ的に心配です。

そこで今回はあまり知られていない？Mavenで安全にパスワードを保存しておく方法を紹介します。

マスターパスワードを設定する

Mavenではマスターパスワードを設定し、それをキーにして各サーバーのパスワードを暗号化して保存します。マスターパスワードの生成は

mvn --encrypt-master-password <password>
[/shell]このコマンドを実行してください。標準出力に

{jJLZkyJ3m5cHQjCxDJwPA91P4n/AMS3mNy8Ltz6UdLs=}

のように暗号化されたパスワードが出力されます。コマンドライン上にパスワードを直接入力するためシェルのヒストリーに残るので注意しましょう。

出力されたパスワードを~/.m2/settings-security.xmlに記述します。

<?xml version="1.0" encoding="UTF-8"?>
<settingsSecurity>
	<master>マスターパスワードはいつものあれですよ {jJLZkyJ3m5cHQjCxDJwPA91P4n/AMS3mNy8Ltz6UdLs=}</master>
</settingsSecurity>

ちなみにブーレスの外の文字列は無視されるので、上記のようにコメントを記述することができます。

サーバーパスワードを設定する

mvn --encrypt-password <password>

サーバーパスワードもマスターパスワードと同じようにコマンドライン上から生成します。settings-security.xmlがないとエラーを出力するので注意しましょう。

ここで出力されたパスワードをsettings.xmlに記述します。

<?xml version="1.0" encoding="UTF-8"?>
<settings>
	<servers>
		<server>
			<id>github.com</id>
			<username>nagaseyasuhito</username>
			<password>{XkXasoj3bu8HgKQeh0lOMHNMo+dRJXKlHvCiVsRJBpE=}</password>
		</server>
		<server>
			<id>mavenrepository.googlecode.com</id>
			<username>nagase@nagaseyasuhito.net</username>
			<password>{0EMvF/Q0QCAHQhOLhAwqrCRC7YjviO1yIrPTPA/JIUI=}</password>
		</server>
	</servers>
</settings>

こんな感じ。serverのidはscmやrepositoryのidを合わせます。

これでMaven実行中にいちいちユーザー名とパスワードを聞かれなくなりました！JenkinsなどのCIサーバーからでもパスワードの入力を気にせずデプロイできるようなりますね。

何かの参考になれば！

POMを書く

scmを書く

まずはscmを記述して、チェックアウト、チェックインをするリポジトリのURLを記述しましょう。GitHubなら以下のような感じです。

<scm>
	<url>http://github.com/nagaseyasuhito/fatsia</url>
	<connection>scm:git:https://github.com/nagaseyasuhito/fatsia.git</connection>
	<developerConnection>scm:git:https://github.com/nagaseyasuhito/fatsia.git</developerConnection>
</scm>

デフォルトではconnectionが使われるので、developerConnectionは記述しなくても大丈夫です。

distributionManagementを書く

distributionManagementはデプロイする先のURLを記述します。ftpやwebdav、scmなどプロバイダーがあればどこにでもデプロイすることができます。

<distributionManagement>
	<repository>
		<id>mavenrepository.googlecode.com</id>
		<url>scm:svn:https://mavenrepository.googlecode.com/svn/trunk</url>
	</repository>
</distributionManagement>

上記はgooglecode上のsvnリポジトリにデプロイする設定です。GitHubにデプロイさせようかと思ったのですが、gitのプロバイダープラグインがイケてないらしく、デプロイできませんでした。バージョンあがれば直るかも？

maven-release-plugin

tagNameFormatはその名の通りタグの名前です。デフォルトは@{project.artifactId}-@{project.version}なのですが、個人的な好みで@{project.version}にしています。

<plugin>
	<groupId>org.apache.maven.plugins</groupId>
	<artifactId>maven-release-plugin</artifactId>
	<version>2.2.2</version>
	<configuration>
		<tagNameFormat>@{project.version}</tagNameFormat>
	</configuration>
</plugin>

maven-deploy-plugin

maven-deploy-pluginではデプロイに必要なプラグインの設定を記述します。distributionManagementのurlから自動的に解決してくれたらいいのにね。

<plugin>
	<groupId>org.apache.maven.plugins</groupId>
	<artifactId>maven-deploy-plugin</artifactId>
	<version>2.7</version>
	<dependencies>
		<dependency>
			<groupId>org.apache.maven.wagon</groupId>
			<artifactId>wagon-scm</artifactId>
			<version>2.2</version>
		</dependency>
		<dependency>
			<groupId>org.apache.maven.scm</groupId>
			<artifactId>maven-scm-provider-svnexe</artifactId>
			<version>1.5</version>
		</dependency>
	</dependencies>
</plugin>

デプロイしてみる

あとは普通にmvn release:prepare release:performすればdistributionManagementで指定したリポジトリにデプロイされます。自分は以下のようなシェルスクリプトを書いてデプロイしています。

#/bin/sh
rm -Rf $1 &&
git clone https://github.com/nagaseyasuhito/$1.git &&
cd $1 &&
mvn clean release:prepare release:perform -B

何かのご参考になれば！