« 2009年10月 | メイン | 2009年12月 »

2009年11月 アーカイブ

2009年11月03日

JavaによるGyazoクローン「Jyazo」

GyazoクローンをJavaで作成しました。
名前はJyazoとしました。
ソースとjarファイルはGithubに公開しています。
Gyazoとの違い
Javaによる実装のため、Mac OS X,Windows,Linux問わず動作するはずですが、開発環境がMacのため他の環境は試せていません。
GyazoはMacのscreencaptureコマンドを使っているため、キャプチャの範囲を選択した後にキャプチャされますが、Jyazoは全画面をキャプチャした後に範囲を選択し、選択範囲を切り抜いています。これは、リアルタイムで処理するのは遅すぎるためです。
マルチディスプレイ環境には未対応です。プライマリディスプレイのみキャプチャするようになっています。
Gyazoが内部的に持っているIDをJyazo独自のものにしています。
IDについて
上記の通り、IDはJyazo独自のものを設定しています。
Gyazoのページには、アップロードファイルの一覧を表示する方法が書かれていますが、多分この機能にIDが使われていると思います。
しかし、これまでこの機能に気付いておらず、Jyazo独自のものを実装していました。
Jyazoの開発終盤にこの機能に気付き、Gyazoで一覧表示を試して見ました。
しかしうまく動作していないようです。
このため、現時点ではJyazo独自のIDを採用したままになっています。
実行環境
Javaのバージョンは1.6以降です。これは、Java1.6から導入されたDesktopオブジェクトを使っているためです。
Gyazoクローンを作成しようとしている方へ
Gyazoの配布パッケージ内には、Gyazoサーバのソースも含まれています。
画像送信のテストを行なうときは、自分の環境にサーバを立てて行なうようにしましょう。
私は最初これに気付かずに、変なデータをGyazoサーバに多数送ってしまいました...。
増井さん、すいませんでした。
やり残し
Windowsの実行形式であるexeファイルの作成。何故か手元の環境でMavenのlaunch4jプラグインが正常に動作しないため保留。
Mac OS Xの実行形式であるappファイルの作成。作成方法はわかっているが、毎回作成するのは面倒なためMavenプラグインで実現したい。なければ作成せざるを得ないかも。
配布パッケージの作成の自動化。Mavenのassemblyプラグインで作成しようとしても、関係のないファイルまで同梱されてしまう。
マルチディスプレイ対応。手元の環境がマルチディスプレイでないため開発できない。awtのfullscreenは個別のディスプレイに対してのみ行なうはずなので、モニタが複数あるときはキャプチャするモニタを選択後に、キャプチャ範囲を選択する仕様になるはず。

2009年11月07日

Jyazoの残作業

やり残し作業の続き
> マルチディスプレイ対応。手元の環境がマルチディスプレイでないため開発できない。awtのfullscreenは個別のディスプレイに対してのみ行なうはずなので、モニタが複数あるときはキャプチャするモニタを選択後に、キャプチャ範囲を選択する仕様になるはず。

環境がないため未対応。

> Windowsの実行形式であるexeファイルの作成。何故か手元の環境でMavenのlaunch4jプラグインが正常に動作しないため保留。

使っていたlaunch4jのMavenプラグインを別のプラグイン「org.bluestemsoftware.open.maven.plugin:launch4j-plugin」に変更したら動作した。

> Mac OS Xの実行形式であるappファイルの作成。作成方法はわかっているが、毎回作成するのは面倒なためMavenプラグインで実現したい。なければ作成せざるを得ないかも。

「org.codehaus.mojo:osxappbundle-maven-plugin」というMavanプラグインを導入した。

> 配布パッケージの作成の自動化。Mavenのassemblyプラグインで作成しようとしても、関係のないファイルまで同梱されてしまう。

assembly識別子のtypoが原因。「include」を間違えていたため、「directory」で指定していたpath配下のファイル全てを同梱していた模様。
たまたま、発見した以下のページを読んで、スキーマを追加して見て初めてわかった事だけど、pom.xmlでは識別子のtypoに警告を発するけど、assemblyでは対応しておらず、オートコンプリートも動作しない。
Eclipse で補完されなくてやきもきしてたので。冒頭の assembly 要素を以下のようにすればおkです。

<assembly xmlns="http://maven.apache.org/plugins/maven-assembly-plugin/assembly/1.1.0"
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xsi:schemaLocation="http://maven.apache.org/plugins/maven-assembly-plugin/assembly/1.1.0 http://maven.apache.org/xsd/assembly-1.1.0.xsd">
新規に行なった事
Linuxのshell scriptで実行ファイルを作成した。
jyazo
#! /bin/sh

shell_script_path=${PWD}"/"${BASH_SOURCE[0]}
jar_file_path=`expr ${shell_script_path} : '\(.*/\)[^\/]*$'`Jyazo-0.0.2-SNAPSHOT.jar
java -jar ${jar_file_path}
毎回、jarファイル名を変更するのは面倒なのでなんとかしたいところ。
仮に、Mavenプラグインが見つかればそちらに移行する予定。
sedコマンドの結果が変数に代入する方法がなく、かなりハマった...。

「#!」の名前は「shebang」

Linuxでよく使うファイル先頭行の「#!」の読み方をすぐ忘れる。
「shebang」と言って、シバンやシェバンと読む。
意味を辞書で調べると、「仕掛け」や「仕組み」という意味。
「#!」と「shebang」に関連性がなさ過ぎて覚えにくいよね。
いい加減に忘れないようにしたいので、絵を書いて覚えるメソッド発動。
題名『銃声に驚く彼女』
題名『銃声に驚く彼女』
よし!
覚えた!
2009/11/09 追記
Wassr経由の情報で、shebangはjargonファイルに載っていることが判明。
また無知を曝け出してしまった...。

「入門git」を読んだ

「あなたが読んだ『入門git』は銀色のgit本ですか? それとも小豆色のGit本ですか?」
「銀色のgit本です」
というわけで、頭文字が小文字の方の『入門git』を読みました。
大文字の方の『入門Git』と発売日が一ヶ月ちょっとしか違わないので、『入門ギット買った』とつぶやかれてもどちらの本か判断つかない状況ですね。
聞いた話によると、大きい方のGit本のほうが高度な内容らしいので、一番最初に手を出すのなら小さいgit本が良いかもしれません。
大きいGit本はまだ持っていませんが、周辺の評判も良いので近々購入予定です。

CVSやSVN等の集中型のバージョン管理システム(VCS)を使っていた人達だけでなく、これまでバージョン管理システムそのものを使った事がない人にもお勧めできる内容です。
大変わかりやすく、大変読みやすく仕上がっていました。
初版の1刷にも関わらず誤植も見当たらず(少なくとも私は気付きませんでした)、非常に丁寧に作られた印象を持ちました。
自分用メモ
小さいgit本を読んで知ったgitコマンドに、自分で調べたgitコマンドの使い方を統合したメモ。
小さいgit本の第5章までに対応している。
第6章以降のコマンドもまとめたかったのだけど、それぞれのコマンドの説明が長くなり過ぎて、メモのフォーマットにあわなくなってきていたのでここで一旦中断した。
機会があれば、残りのコマンドもまとめてみたいと思う。
(このメモだけ見てもgitの本質は理解できないので注意。)
[]は任意

ページャにlvを使っている場合、色分けがされない事がある。この場合、「lv -c」を環境変数等に設定する。

環境変数

GIT_PAGER
GIT_EDITOR

===============

git help [コマンド名]                           ヘルプ
git [コマンド名] --help                         ヘルプ
git help -a                                     全コマンド一覧

git init                                        カレントディレクトリにリポジトリを作成する

git config --global user.name "[ユーザ名]"                      ユーザ名設定する
git config --global user.email "[メールアドレス]"                   メールアドレス設定する
git config --global user.editor "[エディタ]"                        エディタ設定する
git config --global color.ui "auto"                             表示色分けする
git config --global i18n.commitencoding "[文字コード]"          コミットログの文字コードを設定する
git config --global i18n.logoutputencoding "[文字コード]"       ログ表示時の文字コードを設定する
git config --global alias.[ショートカット] "[サブコマンド]"     サブコマンドにショートカットを設定する
git config --global merge.tool "[マージツール]"                 git mergetool実行時に起動するマージツールを設定する

===============

git log                                         ログを全て表示する
git log -[出力するコミット数]                       コミット数を指定してログを表示する
git log --pretty=oneline                        1コミット1行でログを表示する
git log --pretty=format:"[フォーマット指定]"        指定されたフォーマットでログを表示する
git log --since "[時間]"                        指定した時間内のログを表示する
git log --after "[時間]"                        指定した時間内のログを表示する
git log --until "[時間]"                        指定した時間以前のログを表示する
git log --before "[時間]"                       指定した時間以前のログを表示する
git log [コミット名]                                最初から指定されたコミットを含む範囲のログを表示する
git log [コミット名]..                          指定されたコミット直後から直近のコミットまでの範囲のログを表示する(末尾省略はHEAD指定と同義)
git log [開始コミット名]..[終了コミット名]          指定された開始コミット直後から終了コミットを含む範囲のログを表示する
git log HEAD -1                                 先頭のログを表示する
git log HEAD^ -1                                先頭からひとつ前のログを表示する
git log HEAD^^ -1                               先頭からふたつ前のログを表示する
git log HEAD~1 -1                               先頭からひとつ前のログを表示する
git log HEAD~2 -1                               先頭からふたつ前のログを表示する
git log HEAD~2^^ -1                             先頭からよっつ前のログを表示する
git log HEAD^^~2 -1                             先頭からよっつ前のログを表示する
git log HEAD~5..HEAD~1                          先頭からいつつ前からひとつ前までの範囲のログを表示する

フォーマット指定例 "%h %s"
時間指定は"1 seconds","2 minutes","3 hours","4 days"や"2009-09-01"等が可能。
コミット名の部分にはタグ名やHEADも使用可能な模様。
"^"や"~"による相対指定はコミット名やタグ名に対しても可能。

git status                              ステータスを表示する

git add [ファイル名]                        ステージする
git add -i                              対話モードでステージング等を選択する
git add -p                              パッチモードでステージング等を選択する

git tag                                 タグ一覧を表示する
git tag [タグ名]                        タグを付与つける
git tag [タグ名] [タグを打つ場所]           場所を指定してタグをつける

git commit                              ステージからリポジトリにコミットする
git commit -a                           作業ツリーからリポジトリに直接コミットする
git commit -v                           エディタでコミットメッセージを入力する際、差分を表示する
git commit -m "[コミットメッセージ]"        コミットメッセージを指定してコミットする

git mv "[元のパス]" "[新しいパス]"      ファイルやディレクトリを移動する(リネームにも使用可能)
git rm "[パス]"                         ファイルを削除する

===============

git diff                                                                        作業ツリーとステージングエリアの差分を表示する
git diff HEAD                                                                   作業ツリーとリポジトリの差分を表示する
git diff --cached                                                               ステージングエリアとリポジトリの差分を表示する
git diff [コミット名やタグ名やブランチ名]                                           作業ツリーと指定された場所の差分を表示する
git diff [コミット名やタグ名やブランチ名] [コミット名やタグ名やブランチ名]              指定されたふたつの場所の差分を表示する
git diff --cached [コミット名やタグ名やブランチ名]                                  ステージングエリアと指定された場所の差分を表示する
git diff --stat [コミット名やタグ名やブランチ名]                                    作業ツリーと指定された場所の差分の統計を表示する
git diff --stat [コミット名やタグ名やブランチ名] [コミット名やタグ名やブランチ名]       指定されたふたつの場所の差分の統計を表示する


git checkout [ブランチ名]                                                       チェックアウトする
git checkout -b [新しいブランチ名]                                              現在のブランチからブランチを作成しチェックアウトする
git checkout -b [新しいブランチ名] [元にするコミット名やタグ名やブランチ名]         元にする場所を指定してブランチを作成しチェックアウトする
git checkout -f [ブランチ名]                                                        作業ツリーの状態を問わず、強制的にチェックアウトする
git checkout -f [ファイル名]                                                        作業ツリーの状態を問わず、強制的にチェックアウトする

git branch [新しいブランチ名]                                                       現在のブランチからブランチを作成する
git branch [新しいブランチ名] [元にするコミット名やタグ名やブランチ名]                  元にする場所を指定してブランチを作成する
git branch -m [新しいブランチ名]                                                    現在のブランチ名を変更する 既存のブランチ名を指定しても上書きされない
git branch -m [元にするブランチ名] [新しいブランチ名]                               ブランチを指定してブランチ名を変更する
git branch -M [新しいブランチ名]                                                    現在のブランチ名を強制的に変更する
git branch -d [ブランチ名]                                                      ブランチを削除する マージの済んでいないブランチは削除できない
git branch -D [ブランチ名]                                                      ブランチを強制的に削除する


git merge [ブランチ名]              指定されたブランチへの変更を現在のブランチへマージする マージはステージングエリアに反映される
git merge --squash [ブランチ名]     指定されたブランチへの変更をひとつのコミットにまとめて現在のブランチへマージする マージはステージングエリアに反映される

git cherry-pick [コミット名]            指定されたコミットを現在のブランチへマージしコミットする
git cherry-pick -n  [コミット名]        指定されたコミットを現在のブランチへマージしステージングエリアに反映する git commitが必要 -mをつけない場合、最後にcherry-pickしたコミットのメッセージが表示される

git mergetool                       マージでコンフリクトが発生した場合に、コンフリクトを解消するためにマージツールを起動する 環境変数のmerge.toolが登録されていない場合は、環境に沿ったツールを起動する

git rebase [ブランチ名]             指定されたブランチと現在のブランチの分岐点の位置を、指定されたブランチの先端に移動する

git archive --format=[出力形式] --prefix=[ディレクトリ名etc.] [タグ名] > [出力ファイル名]               ファイルを出力する(出力形式にはzip等)
git archive --format=[出力形式] --prefix=[ディレクトリ名etc.] [タグ名] | gzip > [圧縮ファイル名]        出力したファイルを圧縮して保存(出力形式にはtar等)

git clone [リモートリポジトリ]                          リモートリポジトリから複製する
git clone [リモートリポジトリ] [複製先ディレクトリ名]       リモートリポジトリから複製先を指定して複製する

===============

対話モードでステージする
git add -i
1: [s]tatus             ステータスを表示
2: [u]pdate             ステージするファイルを選択する画面に遷移する
3: [r]evert             ステージングエリアから戻すファイルを選択する画面に遷移する
4: [a]dd untracked      新たにステージするファイルを選択する画面に遷移する
5: [p]atch              パッチモード ファイル内の変更(hunk)をするファイルを選択する画面に遷移する ファイルを選択した後にhunkを選択する画面に遷移する
6: [d]iff
7: [q]uit               対話モードを抜ける
8: [h]elp
ファイル選択では、選択されたファイルの横に*が表示される(選択時に数字の前に-をつけると取り消しが可能)
hunk選択では、hunkに対する処理を選択する
y:      変更を受け入れる
n:      変更を受け入れない
a:      以降のhunkを全て受け入れる
d:      以降のhunkを全て受け入れない
/:
e:
?:

===============

.gitignore              gitが無視するファイルを定義するファイル(定義を共有する場合)
.git/info/exclude       gitが無視するファイルを定義するファイル(ローカルリポジトリ単位)

2009年11月10日

できるだけ簡単にMacでローカルにGyazoサーバを立てる方法

「Gyazoの手軽さは便利そうだけど、パブリックな場所に公開されるのはちょっと...。」とお考えのあなた、良い方法ありますよ。
(MacOSXの基本的な操作と、ターミナルを使える人を対象とします。)
Gyazoには画像をアップロードするコードだけでなく、サーバ側のスクリプトも同梱されています。
(現行のバージョン0.3には含まれません。今回は0.2のものを使用します。)
そこでローカルにGyazoサーバを立ててみましょう。
方針は、できるだけOS標準機能を使い、ソースの修正も最小限に抑える方向となっています。
RubyのサーバであるWEBrickを使った方法は、以下のページに詳解されています。
参考にしたのは次のページ。
本来であれば、0.2に入っている「upload.cgi」を使えば良いのですが、Rubyの実装に変更があったためそのままでは動作しません。
「Digest::MD5.new(imagedata).to_s」の部分を「Digest::MD5.new.update(imagedata).to_s」に変更します。
(MacOSX 10.5の場合。これ以前のOSXでは修正が不要かもしれません。)
また、「upload.cgi」は、同一ディレクトリにファイルを保存するため、実行環境配下に画像ファイルが入ってしまいます。
これでは、画像ファイルが実行ファイルと認識されてしまうため、ブラウザから参照する事ができません。
(仕様的にcgiファイルでも受け取り実行環境に配置されてしまうため、セキュリティ的にも危険です。)
このため、画像を受け取る専用のアカウントを作成し、実行環境下でない「サイト」フォルダ(内部的にはSitesフォルダ)に保存するようにします。
さらに、ブラウザに通知する保存先URLも変更します。
GyazoはGNU GPLらしいので、上記の修正済「upload.cgi」を載せておきます。
こちらのファイルもGPLになります。
upload.cgi
#!/usr/bin/env ruby
# -*- ruby -*-
#
# $Date$
# $Rev$
#
require 'cgi'
require 'digest/md5'
require 'sdbm'

cgi = CGI.new("html3")

id = cgi.params['id'][0].read
imagedata = cgi.params['imagedata'][0].read
#hash = Digest::MD5.new(imagedata).to_s
hash = Digest::MD5.new.update(imagedata).to_s

dbm = SDBM.open('db/id',0644)
dbm[hash] = id
dbm.close

#File.open("data/#{hash}.png","w").print(imagedata)
File.open("/Users/gyazo/Sites/#{hash}.png","w").print(imagedata)

#cgi.out { "http://localhost/#{hash}.png" }
cgi.out { "http://localhost/~gyazo/#{hash}.png" }
Gyazo専用アカウントの作成
アカウントの設定で次のようなユーザを作成します。
Gyazo専用クライアントの設置
Gyazo専用クライアントの設置
Gyazoサーバの設定
上記の「upload.cgi」はホームディレクトリに保存したと仮定します。
以下、ターミナルを使って設定していきます。
% cd /Library/WebServer/CGI-Executables
% mkdir gyazo
% sudo chown _www:admin gyazo 
% sudo chmod 755 gyazo
% sudo mv ~/upload.cgi .
% sudo mkdir db
% sudo chown _www:admin upload.cgi db
% sudo chmod 755 upload.cgi db
% cd /Users/gyazo
% sudo chown _www:admin Sites
% cd Sites
% sudo rm -rf *
% sudo rm -rf .*
これで完了です。
「Web共有」を起動して下さい。
Gyazoクライアントの改造
Gyazoクライアントを改造し、画像の送信先を変更します。
そのまま改造すると通常のGyazoと区別がつかなくなりますので、コピーしてからカスタマイズを行ないます。
Gyazoの実行用パッケージは、バージョンが0.2では「gyazo.app」、0.3では「Gyazo.app」となります。
両者の中身は基本的に同じですのでどちらを使用しても構いません。
ここでは、複製したGyazoを「local_gyazo.app」とします。
「local_gyazo.app」を右クリックし、「パッケージの内容を表示」を選択して下さい。
パッケージ内の「Contents/Resouces/script」というファイルをエディタで開いて下さい。
HOST = 'gyazo.com'
CGI = '/upload.cgi'
という部分を
HOST = 'localhost'
CGI = '/cgi-bin/gyazo/upload.cgi'
に書き変えて保存します。
実行
「local_gyazo.app」を実行しキャプチャしてみましょう。
「http://localhost/~gyazo/」で始まるURLがクリップボードにコピーされ、ブラウザに画像が表示されたのであれば、ローカルGyazoサーバの設置は完了です。

2009年11月14日

Mac版Gyazoでウィンドウを綺麗にキャプチャする方法

大袈裟な話じゃなくて簡単。
・Mac版のGyazoは画面のキャプチャにコマンド「screencapture」を使っている
・「screencapture」は「Shift+Command+3」や「Shift+Command+4」で使用しているスクリーンショットと同じもの
・Gyazoでは「Shift+Command+4」と同じ「screencapture -i」を実行する
・「screencapture -i」は選択範囲のキャプチャだけではなく、選択したウィンドウのキャプチャもできる
・キャプチャの範囲選択待ちの時にスペースを押すと、ウィンドウ選択に切り替わる
つまり、Gyazoを起動してスペースを押すとウィンドウの選択になります。
ウィンドウの選択はマウスをクリックするだけ。
範囲選択に戻すには、もう一度スペースを押して下さい。
このコマンドの素晴らしいところは、影の部分もアルファチャンネルを使ってキャプチャしてくれるところです。
ウィンドウ選択によるGyazoの結果
ウィンドウ選択によるGyazoの結果
透過させているウィンドウを範囲選択でキャプチャすると背景まで写り込んでしまいますが、ウィンドウ選択でキャプチャすると写り込みません。
範囲選択による透過ウィンドウのGyazoの結果
範囲選択による透過ウィンドウのGyazoの結果
ウィンドウ選択による透過ウィンドウのGyazoの結果
ウィンドウ選択による透過ウィンドウのGyazoの結果
影は不要という方は、Gyazoのパッケージ内の「/Contents/Resources/script」というファイル内の「screencapture」に「o」オプションを追加して下さい。
(ここは敢えてわかりにくく書いています。書いてある意味がわからない場合は、変更しない方が無難です。)
影なしオプションを追加したウィンドウ選択によるGyazoの結果
影なしオプションを追加したウィンドウ選択によるGyazoの結果
Windows版やLinux版でできるかどうかは不明です。
2009/11/14 追記
Twitterで以下のようなコメントをもらった。
@kanasan キャプチャ前に,cmd->Tabしてフォーカスうつしてから <Space>クリック したほうがさらに綺麗かと! http://bit.ly/4AxzlF
ウィンドウ選択によるフォーカスのあるウィンドウのGyazoの結果
ウィンドウ選択によるフォーカスのあるウィンドウのGyazoの結果
確かに!

2009年11月21日

LeopardでJava6を標準のJavaにする

LeopardにJava6のJDKを入れても、Java系のコマンドはJava5が実行されていた。
JyazoはJava6で導入された機能を使っており、本来ならJava5の環境ではコンパイルできないのだが、Eclipseが賢いのかMavenが賢いのかわからないが、ヨロシクやってくれていた。
しかし、Mavenのプラグイン、maven-release-pluginのrelease:prepareゴールを実行する必要が出てきた。
EclipseとMavenを連携させるm2eclipseというEclipseのプラグイン上で設定できれば良いのだが、設定方法がわからない。
terminal上から実行しようとしても、バージョンがあわないので怒られる。
仕方がないので、LeopardのJava環境がJava6にならないかと調べてみた。
細かい事は省いて重要な部分だけ。
% which java
/usr/bin/java
 ls -al /usr/bin/ | grep ja
lrwxr-xr-x    1 root   wheel           73  9 12 05:58 jar@ -> /System/Library/Frameworks/JavaVM.framework/Versions/Current/Commands/jar
lrwxr-xr-x    1 root   wheel           79  9 12 05:58 jarsigner@ -> /System/Library/Frameworks/JavaVM.framework/Versions/Current/Commands/jarsigner
lrwxr-xr-x    1 root   wheel           74  9 12 05:58 java@ -> /System/Library/Frameworks/JavaVM.framework/Versions/Current/Commands/java
lrwxr-xr-x    1 root   wheel           75  9 12 05:58 javac@ -> /System/Library/Frameworks/JavaVM.framework/Versions/Current/Commands/javac
-r-xr-xr-x    1 root   wheel        50976  2 20  2008 javaconfig*
lrwxr-xr-x    1 root   wheel           77  9 12 05:58 javadoc@ -> /System/Library/Frameworks/JavaVM.framework/Versions/Current/Commands/javadoc
lrwxr-xr-x    1 root   wheel           75  9 12 05:58 javah@ -> /System/Library/Frameworks/JavaVM.framework/Versions/Current/Commands/javah
lrwxr-xr-x    1 root   wheel           75  9 12 05:58 javap@ -> /System/Library/Frameworks/JavaVM.framework/Versions/Current/Commands/javap
-r-xr-xr-x    1 root   wheel        72336  2 20  2008 javatool*
lrwxr-xr-x    1 root   wheel           76  9 12 05:58 javaws@ -> /System/Library/Frameworks/JavaVM.framework/Versions/Current/Commands/javaws
「/usr/bin/」直下にはjava本体はなく、「/System/Library/Frameworks/JavaVM.framework/Versions/Current/」配下のコマンドにリンクが張られていることがわかった。
% ls -al /System/Library/Frameworks/JavaVM.framework 
total 72
drwxr-xr-x   12 root  wheel   408  9 12 05:59 ./
drwxr-xr-x  107 root  wheel  3638  1  4  2008 ../
lrwxr-xr-x    1 root  wheel    27  9 12 05:58 Classes@ -> Versions/CurrentJDK/Classes
lrwxr-xr-x    1 root  wheel    24  9 12 05:59 CodeResources@ -> Versions/A/CodeResources
lrwxr-xr-x    1 root  wheel    28  9 12 05:58 Commands@ -> Versions/CurrentJDK/Commands
lrwxr-xr-x    1 root  wheel    27  9 12 05:59 Frameworks@ -> Versions/Current/Frameworks
lrwxr-xr-x    1 root  wheel    24  9 12 05:59 Headers@ -> Versions/Current/Headers
lrwxr-xr-x    1 root  wheel    24  9 12 05:58 Home@ -> Versions/CurrentJDK/Home
lrwxr-xr-x    1 root  wheel    23  9 12 05:59 JavaVM@ -> Versions/Current/JavaVM
lrwxr-xr-x    1 root  wheel    29  9 12 05:58 Libraries@ -> Versions/CurrentJDK/Libraries
lrwxr-xr-x    1 root  wheel    26  9 12 05:59 Resources@ -> Versions/Current/Resources
drwxr-xr-x   14 root  wheel   476  9 12 05:59 Versions/
「Version」配下が怪しいですな。
% ls -al /System/Library/Frameworks/JavaVM.framework/Versions 
total 56
drwxr-xr-x  14 root  wheel  476  9 12 05:59 ./
drwxr-xr-x  12 root  wheel  408  9 12 05:59 ../
lrwxr-xr-x   1 root  wheel    5  9 12 05:58 1.3@ -> 1.3.1
drwxr-xr-x   3 root  wheel  102 11  3  2007 1.3.1/
lrwxr-xr-x   1 root  wheel    5  9 12 05:59 1.4@ -> 1.4.2
lrwxr-xr-x   1 root  wheel    3  5  9  2008 1.4.1@ -> 1.4
drwxr-xr-x   8 root  wheel  272  1  3  2008 1.4.2/
lrwxr-xr-x   1 root  wheel    5  9 12 05:59 1.5@ -> 1.5.0
drwxr-xr-x   8 root  wheel  272  1  3  2008 1.5.0/
lrwxr-xr-x   1 root  wheel    5  9 12 05:59 1.6@ -> 1.6.0
drwxr-xr-x   8 root  wheel  272  5  9  2008 1.6.0/
drwxr-xr-x   8 root  wheel  272  9 12 05:59 A/
lrwxr-xr-x   1 root  wheel    1  9 12 05:59 Current@ -> A
lrwxr-xr-x   1 root  wheel    3  9 12 05:58 CurrentJDK@ -> 1.5
古いバージョンのJavaも綺麗に整理されて配置されていた。「A」ディレクトリってなんでしょうな。
% ls -al /System/Library/Frameworks/JavaVM.framework/Versions/A/
total 528
drwxr-xr-x   8 root  wheel     272  9 12 05:59 ./
drwxr-xr-x  14 root  wheel     476 11 21 21:07 ../
-rw-r--r--   1 root  wheel    1524  7 31 09:35 CodeResources
drwxr-xr-x  37 root  wheel    1258  9 12 05:58 Commands/
drwxr-xr-x   4 root  wheel     136  6 27 18:09 Frameworks/
drwxr-xr-x  16 root  wheel     544  9 12 05:59 Headers/
-rwxr-xr-x   1 root  wheel  263120  7 31 09:35 JavaVM*
drwxr-xr-x  33 root  wheel    1122  9 12 05:59 Resources/
よくわからない。
まあ、「CurrentJDK」のリンク先を変更すればなんとかなるかもしれないので試してみる。
% cd /System/Library/Frameworks/JavaVM.framework/Versions/
% sudo rm CurrentJDK
% sudo ln -s 1.6.0 CurrentJDK
で、「maven-release-plugin」を実行してみたらエラーも起きずに動作した。
問題解消。

MavenとGitHubの連携

Mavenはプロジェクトのバージョンを「x.x.x-SNAPSHOT」のように管理するのが標準のようだ。
「SNAPSHOT」は開発中を示す。
Mavenで管理しているJyazoのプロジェクトのソースをGitHubで管理しようとすると、リリース時に次のようなオペレーションになってしまう。
pom.xml内に書かれているプロジェクトのバージョンから「-SNAPSHOT」を削除
git commit -aを実行
git tagを実行
git push origin masterを実行
pom.xml内のプロジェクトのバージョンを挙げて「-SNAPSHOT」を追加
git commit -aを実行
git push origin masterを実行
面倒くさい。
なんとかならないものかと調べていると、Twitterで以下のような情報を頂いた。
@kanasan 使ったことは無いんですが maven-release-plugin で何とかできるそうです。 [たいぷぴぃ]
そこでmaven-release-pluginを調べてみた。
まず、1.「リリースタグを付ける」などのリリース前準備を行うため、次のコマンドを実行します。

C:\work\6\webdb-webapp_1_0_x> mvn release:prepare

リリースバージョン名などを聞かれますので、デフォルトのままでよければEnterキーを押します。このコマンドでは、次のような作業が行われました。

   1. コミットしていないソースコードがないかチェック
   2. SNAPSHOTバージョンのライブラリに依存していないかチェック
   3. pom.xmlのバージョン設定「1.0.0-SNAPSHOT」を「1.0.0」に変更
   4. ビルド
   5. 変更したpom.xmlをバージョン管理(Subversion)にコミット
   6. バージョン管理へのリリースタグ付け(webdbwebpp-1.0.0)
   7. pom.xmlのバージョン設定を、次の開発バージョン「1.0.1-SNAPSHOT」に変更
   8. 変更したpom.xmlをバージョン管理(Subversion)にコミット
なるほど。これは良い。
しかし、Subversionとの連携については色々見つかったが、gitやGitHubとの連携については探しきれなかった。
検索範囲を日本語以外に広げて探していたら次のようなページが見つかった。
長文で最初は怖じ気づいたが、良く見ると書いていることはそんなに難しい内容ではないようだ。
gitのインストールやGitHubのアカウント取得方法とSSHのキーの登録、Mavenのインストールやpom.xmlの作成やGitHubでのレポジトリの作成等、非常に丁寧に細かく書いている様子。
で、Step 9.にMavenとGitHubを連携するための設定と思しき記述を発見。
これをもとに、手元のプロジェクトのpom.xmlに以下の設定を追記した。
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd">
<!--略-->
  <scm>
    <connection>scm:git:git@github.com:Kanasansoft/Jyazo.git</connection>
    <url>scm:git:git@github.com:Kanasansoft/Jyazo.git</url>
    <developerConnection>scm:git:git@github.com:Kanasansoft/Jyazo.git</developerConnection> 
  </scm>
<!--略-->
  <build>
<!--略-->
    <plugins>
<!--略-->
      <plugin>
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-release-plugin</artifactId>
        <version>2.0-beta-9</version>
      </plugin>
<!--略-->
    </plugins>
<!--略-->
  </build>
<!--略-->
</project>
前のエントリーの通り、Eclipse上で実行する方法がわからなかったので、プロジェクト配下(同時にgit管理かでもある)で、以下のコマンドを実行した。
% mvn release:prepare
[INFO] Scanning for projects...
(略)
そうすると、途中で次のように聞かれる。
What is the release version for "Jyazo"? (com.kanasansoft.Jyazo:Jyazo) 0.0.3: : 
What is SCM release tag or label for "Jyazo"? (com.kanasansoft.Jyazo:Jyazo) Jyazo-0.0.3: : 
What is the new development version for "Jyazo"? (com.kanasansoft.Jyazo:Jyazo) 0.0.4-SNAPSHOT: : 
つまり、(1)「今からコミットするプロジェクトのバージョンの指定」、(2)「コミットにつけるタグの名前」、(3)「コミットした後にプロジェクトにつけるのバージョンの指定」。
ここまでのバージョンは「0.0.3-SNAPSHOT」だったため、(1)には「0.0.3」を指定した。
入力しなくても既定と同じだったのでそのままEnter。
(2)は余り考えずにそのまま既定値。
(3)も勝手にバージョンを挙げて「-SNAPSHOT」をつけたものが既定だったためそのまま。
たったこれだけで、最初に「面倒くさい。」と言っていた作業を全部やってくれた。
ちょっと感動して興奮した。
maven-release-pluginが直接GitHubにpushしに行っているようなので、一人で開発していたとしてもローカルリポジトリのソースは古くなっている点に注意。
後は、「Jyazo-0.0.3」タグのついているやつをpullしてパッケージ化してGitHubのDownloadのところにアップするも良し、「0.0.4-SNAPSHOT」をpullして開発を続けるも良し。
pullの仕方を忘れたので、銀のgit本見てくる。
関連するエントリー
2009/11/22 追記
考えてみたら、ローカルリポジトリと同期すればローカルは常に最新状態かも...。
でも、ローカルでつけられたタグはGitHubとどうやって同期するのかわからない...。
2009/11/22 追記2
「mvn release:prepare」を実行した後は「mvn release:perform」を実行して、パッケージ化したファイルを公開サーバに転送するらしい。
ところがJyazoは公開サーバを持っておらず、GitHub上でやりくりしようと思っていたので、pom.xmlには「distributionManagement」が存在しない。
このような場合、「mvn release:perform」は実行途中でエラーとなる。
「mvn release:perform」が正常に行なわれなかった場合、次の「mvn release:prepare」は何もしてくれない。
メッセージには「Release preparation already completed. You can now continue with release:perform, or start again using the -Dresume=false flag」と書かれていた。
「release:perform」を実行するか「-Dresume=false flag」をつけて実行し直すからしい。
そこで、「mvn release:prepare -Dresume=false」と実行してみたところ、GitHubと連携した。
(ローカルにも「SNAPSHOTのないバージョンのパッケージ」が生成されている。)
これは気付かないとちょっとはまりそうだ。