仕事で使ってる社内のjavaライブラリがあるんだけどこれが昔ながらのantのみのモジュールでつくられていた。まぁわざわざmaven化するほど困ってるわけではないんだけども、このライブラリはいくつかのプロジェクトで利用されていて、バージョン管理とかをきちんとしたいのとmavenの練習になるかなってことでこのプロジェクトをmaven化してみた。
依存ライブラリの解決
まずは依存*1しているライブラリの洗い出し。
最初、eclipseのmavenプラグインを使ってEclipseから検索してpom.xmlを書き換えてたんだけど、途中でなぜかバグって依存ライブラリの記述が全部消えたorz。なんというかEclipseのプラグインって完成度がまちまちだからこういうことがよくあるんだよな。これでますますEclipseを離れたくなった。Eclipseも嫌いじゃないけど、やっぱ俺はemacsラブ。marabal-mode最高...と言いたい。
ということで素直に下記サイトで地味に検索して依存関係を潰していった。
このサイトの検索ボックスにライブラリの一部の文字列を入力すると検索結果がでるのでそこからめぼしのものを選んでdetailリンクをクリックすると、pom.xml用のタグが表示される。mavenのリポジトリは他のツールでも利用してるらしくmaven用ツールのほか、いろいろな依存関係の記述例が表示されるのが気になった。
これら依存関係のタグをpom.xmlにコピペしてその都度
$ mvn compile
していきながらコンパイルが成功するまで地味な作業の繰り返していった。
java-mail
その途中でjava-mailの依存関係を解決できなかった。このjarはmvnrepository.comの検索では見つかるものの、いざコンパイルをかけるとダウンロードでこけてしまう。ここをみるとライセンス的に怪しいという。
http://d.hatena.ne.jp/shinsuke_sugaya/20060503/1146608133
もともとmvnrepository.comにあったものが、移動したのだろうか？
その後、ググッて見つけた以下を参考にして新しくリポジトリを追加することで解決した。
http://d.hatena.ne.jp/Aileron/20091207/1260175613
<dependency>
<groupId>javax.mail</groupId>
<artifactId>mail</artifactId>
<version>1.4.2</version>
</dependency>
<repositories>
<repository>
<id>maven-repository.dev.java.net</id>
<name>Java.net Maven Repository</name>
<url>http://download.java.net/maven/2/</url>
</repository>
</repositories>
joglのリポジトリ
ところでこのリポジトリのURLはjava.netである。たしかjoglがjava.netで開発されてたので気になって検索してみたらあった。
http://download.java.net/maven/2/net/java/jogl/jogl/
joglもjava.netのリポジトリには登録されてるのね。rcというのが気になるけどこれを気にjoglのmavenを使ったビルド環境をもう一度見直してみよう。
社内リポジトリ
とまぁそんな地味な作業を重ね、ビルドが成功するようになった。完成したjarを社内リポジトリにインストールしたい。
## jarを生成
$ mvn package
まず、mavenの社内リポジトリをおく場所。これはsvnリポジトリをおいてる場所と同じにした。このsvnにはssh経由でアクセスしてunixユーザの権限で管理しているのでmvnリポジトリも同様にしたい。
| リポジトリID | hoge.com |
| リポジトリURL | ssh 192.168.1.1:/usr/local/maven2repo |
そこでまずリポジトリ用のディレクトリを作成した。
$ ssh -A 192.168.1.1
$ cd /usr/local/
$ sudo mkdir maven2repo
$ sudo chown -R root:dev maven2repo
$ sudo chmod -R 774 maven2repo
$ sudo chmod g+s maven2repo
devグループに属す人なら誰でもアクセスできるようにしたつもり。
で、今回maven化したプロジェクトのpom.xmlに以下のように登録先の情報を記述する。
<distributionManagement>
<repository>
<id>hoge</id>
<name>Hoge Repository</name>
<url>scpexe://192.168.1.1/usr/local/maven2repo</url>
</repository>
</distributionManagement>
ビルド作業しているホストの以下のディレクトリにsettings.xmlを準備する。
- ~/.m2/settings.xml
<?xml version="1.0" encoding="UTF-8"?>
<settings>
<servers>
<server>
<id>hoge.com</id>
<username>${username}</username>
<filePermissions>664</filePermissions>
<directoryPermissions>775</directoryPermissions>
<configuration>
<sshExecutable>ssh</sshExecutable>
<scpExecutable>scp</scpExecutable>
</configuration>
</server>
</servers>
</settings>
デプロイコマンドは以下
$ cd ~/dev/goocore
$ mvn deply
以上でデプロイ完了
今回ハマったのは、ssh -A のようにエージェントフォワードしてる環境でのscpによるデプロイ方法。ググッてすぐに出てくるのはみな、usernameとprivatekeyのパスを設定する例ばかりで、今回のように鍵はエージェントフォワードしてる場合の設定例がなかなか見つからない。そんななか下記の参考を発見できたおかげで無事解決できた。感謝です！てかマニュアルちゃんと読めって話だよね。
所感
今回の作業のなかでivyというビルドツールの存在を知ったのだが、これがなかなか良さげ。このツールはantのタスクで、mavenのリポジトリを流用してjarの依存関係を解決してくれる。対するmavenは確かに便利なんだけども、依存関係の解決以外にたくさんの機能が備わっててものすごく大袈裟に見える。そもそもこれらの機能はほとんどど使わないし、中身はブラックボックスだからビルド方法を変えようと思っても気軽に拡張できない。その点ivyはantのいちタスクであるため、見通しもいいし簡単にビルドルーチンを改造できる。仕事で使ってるプロジェクトはどれも小規模なものばかりなので、mavenではオーバースペックかもしれない。そう考えると、ほんとに大規模なプロジェクト以外はどれもantですまして、必要に応じてivyを使ったりするのがべストかもしれない。mavenには豊富なプラグインが用意されていてリリースツールや継続的インテグレーションツールなどとの連携が充実してるように見える。しかし、これについてはantにもいえそうなことで、大抵antタスクがあるような気がする。逆にmavenからの利用だと導入コストが高そう。軽量そうなivyと重厚なmaven。どちらかというとivyのほうが魅力的に思える。とはいってもmalabar-mode使うにはpom.xmlが必要だから結局mavenを使いそうだけども。
ivyとかビルドのことについて、以下のサイトとその先の紹介サイトが大変参考になりました。
http://d.hatena.ne.jp/wyukawa/20101122/1290440174
*1：どうでもいいけど「依存」って「いそん」て読むんだよね。「既存」も「きそん」。アナウンサーとかの発音きくとわかるよ。この業界「既存」を使うことが非常に多いんだけど、いまだかつて「きそん」と発音する人を見たことががない。ただし「保存」は「ほそん」ではなくて「ほぞん」だよ。