第3章 Subversionベストプラクティス
Authors:YOSHIHARA Hidehiko
サードパーティ製品のライブラリのバージョン管理は、バージョンアップの頻度や依存性などが外部要因に左右されること、ライブラリは共有して使われることから影響範囲も広いことなど、ソースコードのバージョン管理とはまた違った問題が発生します。
本特集で取り上げるMaven 2を使用することで、ライブラリのバージョン管理が効率的に行うことができます。
おや、Webサイトを眺めていたM子ちゃんが、憂鬱そうな溜息をついています…。
M子●K太君、○○○．jarのバージョンが上がったみたいよ。
結構、重要なバグが修正されているみたいだからバージョンを上げておいてね。
K太●またですか。このごろ頻繁ですね。この前はバージョンを上げたあとに別の障害が見付かって、
また元のバージョンに戻しましたよ。もう少し、待っていたほうが良いような気がしますが。
M子●でも、新しいバージョンに作ろうと思った機能が追加されているみたいだから、バージョンを変えておいたほうが開発が進みそうよ。
K太●依存しているJARファイルのバージョンも変わってます。必要なJARも増えてますね。あーあ、面倒くさいなあ。
O先輩●JARの管理は確かにやっかいだね。
バージョン管理から漏れることもよくあるから。プロジェクトをMaven2で管理するよい機会かもしれないぞ。
M子●Maven2ですか。よく周りから勧められるんですが難しそうで、情報もあまり見つけだすことができなかったので手をつけていません。
O先輩●よいタイミングだったね、ちょうどWEB+DB Press Vol,39の特集1の第4章以降（42ページ）に詳しい内容が掲載されているよ。
K太●うはー。また覚えなきゃいけないことが増えたよ。
O先輩●Maven2は最初は難しく感じるかもしれないけど、JARのバージョンやその依存関係をpom.xmlと呼ばれる定義ファイルで自動的に管理してくれるから楽になるよ。それに、JARの管理だけでなくビルドやリリースの機能も兼ね備えているから何かと重宝するよ。
JARファイルのように外部で作成されるライブラ
リそのものを、開発に使用しているメインラインに組み込んだ場合、ライブラリのバージョン変更に伴いライブラリファイル名の変更や依存ライブラリの増減、その変更タイミングなどでコードラインの品質が不安定な状態に落ちる危険性があります。
コードラインの安定性についてはライブラリ変更用のブランチを作成して行うことで回避できますが、それ以上にライブラリのバージョン管理そのものが難しいという問題があります。
たとえばhoge.jarという名のライブラリを使用する場合、そのままだとライブラリベンダーから提供された現在のライブラリのバージョンを判別できません。ファイル名を、バージョン番号を含めたhoge-1.2.jarに変更してバージョンを明記する方法がよく行われますが、バージョン変更のたびにファイル名が変わるということは、ファイル名でもバージョン管理が行われるという結果を招き、コードラインそのもののバージョン管理が複雑になります。
今回の特集で取り上げているMaven 2を使用すれば、プロジェクト定義ファイル（pom.xml）でライブラリのバージョン管理が行えるようになります。
ライブラリファイルそのものはバージョン管理の対象から外し、代わりにpom.xmlでバージョン管理を行うことによってコードラインの見通しがよくなります。また、ほかのコードライン間とのマージ作業が楽になります。
![[Backlog] - Subversion -](../images/ad-backlog-svn.gif)