第1章
構成管理入門 　

第2章
Subversionによるバージョン管理入門

第3章
Subversionベストプラクティス

第4章
Maven2によるビルド入門

第5章
Maven2ベストプラクティスリリースの自動化

第6章
リリースの自動化

Appendix
Maven 2はまり道


※WEB+DB PRESS Vol.39掲載の記事を載せています。

第5章　Maven2ベストプラクティス

Authors:YAMAMOTO Ryuzo

社内リポジトリ　- 自分たちのライブラリ置き場

前章にて、Maven 2によるライブラリ管理の便利さ・強力さを実感していただけたかと思います。 そうなると次は、セントラルリポジトリに登録されているライブラリと同じように、 自分たちで作ったライブラリなどの成果物も、Maven 2で利用できるようにしたくなりませんか？

たとえば、社内で便利なユーティリティクラスを集めたライブラリを作ったとしましょう。 これまでであれば、そのライブラリのJARファイルをプロジェクトに含めて利用していました。もちろんこの便利ライブラリそのものの開発も進むので、 「どのバージョンを使用しているんだっけ？」「新バージョンを試したいんだけど、どこにある？」 「バグが見付かったから直したやつちょうだい？」ということになるでしょう。
前章で説明したローカルリポジトリへの登録を行えばMaven2でも利用することができますが、すべての開発者が「mvn install:install-file」をやらなければいけないのは面倒ですし、 せっかくのMaven 2のメリットを活かせていませんね。

セントラルリポジトリに登録されているライブラリと同様に、pom.xmlにdependency定義を書くだけで利用できるようにしたいものです。 そこで登場するのが「社内リポジトリ」です。このようなリモートリポジトリのことを一般的には 「インハウスリポジトリ」と呼びますが、本特集では「社内リポジトリ」と呼ぶことにします。
社内リポジトリのメリットを整理すると、次のようになります。
社内リポジトリは、セントラルリポジトリとは違い一般公開しないリモートリポジトリですので、認証を設定し、権限を持っている人だけがアクセスできるリポジトリにすることもできます。

社内リポジトリの構築

社内リポジトリを構築するために必要なものは基本的に次の2つです。 以下で構築の仕方を説明していきますが、本特集のサンプルファイルには構築済みのサーバを用意していますので「サクっと試してみたい」方は、以下を行わなくとも社内リポジトリを利用できます。サンプル社内リポジトリはC:\webdb39\server\tomcat にあります。Tomcat に同梱されているwebdavアプリケーションを利用して、「ライブラリを公開するしくみ」と「ライブラリを転送・配置す るしくみ」を兼ねた社内リポジトリを構築しました。
  1. リポジトリIDとURLを決める
    2. まずはリポジトリIDとURLを決めます。
    リポジトリIDはそのリポジトリを一意にあらわす名前です。特に命名規則があるわけではありませんので自由に指定できますが、「central」というリポジトリIDはセントラルリポジトリをあらわしますので使用できません。リポジトリIDには、リポジトリURLのドメイン部分（gihyo.jpなど）を利用するとよいでしょう。
    サンプル社内リポジトリのID、URLは以下です。


  2. リポジトリとして利用するディレクトリを用意する
    3. JARファイルやpom.xmlを配置するためのディレクトリを用意します。このディレクトリの扱いのポイントは、


    になります。SSHを利用して配置する場合は各開発者のアカウントを同一グループに含めるなどするのがよいでしょう。
    サンプル社内リポジトリのディレクトリは、C:\webdb39\server\tomcat\webapps\maven2です。

  3. そのディレクトリが１．で決めたURLで閲覧できるようにWebサーバを設定にする
    4. 環境によっていろいろ異なる設定になるかと思いますが、Apache HTTP Serverの場合は、たとえば リスト1のような設定になります。この例では、ディレクトリは/usr/local/maven/repo、URLはhttp://gihyo.jp/maven/repoです。

    ●リスト1 httpd.confの設定例 
    ...
<VirtualHost *>
  ServerName gihyo.jp
  ...
  Alias /maven/repo /usr/local/maven/repo
  <Directory "/usr/local/maven/repo">
    Options Indexes FollowSymlink
    order Allow,Deny
    Allow from all
  </Directory>
  ...
</VirturalHost>
...
  4. 各開発者がライブラリをそのディレクトリに配置できるようにする
    5. たとえばSSH（SCP）にてライブラリを配置するためには、各開発者のアカウント（UNIXユーザ）を作成します。
    サンプル社内リポジトリでは、WebDAVを利用しています。ユーザ名はemuko、パスワードもemukoです。


◆　◆　◆

環境によってさまざまな設定方法がありますので、ここで紹介した内容はほんの一例です。Subversionと社内リポジトリのユーザ認証をLDAPなどで一元化したり、Apacheのアクセス制限機能を設定したりと、安全で使いやすい社内リポジトリを構築・運用してください。

社内リポジトリへのライブラリの配置

ここでは、できあがったライブラリを社内リポジトリに配置する手順を説明していきます。

■サンプルの準備
試しに配置するライブラリのMavenプロジェクトは、サンプルのSubversionリポジトリに用意しています。 このライブラリは、「webdb- utils」というライブラリで、文字列「Hello World!」を返すだけの機能を持つユーティリティクラスが含まれます。 プロジェクトをSubversionから、C:\work\5\ webdbutilsにチェックアウトします。 

C:\work\5> svn checkout file:///C:/webdb39/5/repo/trunk webdb-utils


WebDAVによるライブラリの配置を行うにはwagon-webdavプラグインが必要ですので、リスト2をpom.xmlに追加してください。

●リスト2 wagon-webdavプラグインの設定 

<project>
  ...
  <build>
    <extensions>
      <groupId>org.apache.maven.wagon</groupId>
      <artifactId>wagon-webdav</artifactId>
    </extensions>
  </build>
  ...
</project>
また、C:\webdb39\server\tomcat\bin\startup.batを実行し、サンプル社内リポジトリサーバを起動しておいてください。 起動後にWebブラウザでhttp://localhost:18080/maven2/にユーザ名emuko、パスワードemukoでアクセスすれば、空っぽの社内リポジトリが表示されます。
  1. 配置場所の指定
    2. まずpom.xmlのdistributionManagement要素に配置する場所を指定します。
    サンプルではリスト3の指定を行ってください。

    ●リスト3 配置場所の指定（サンプルの場合） 
    <project>
  ...
  <distributionManagement>
    <repository>
      <id>gihyo.jp</id>
      <name>Gihyo Repository</name>
      <url>dav:http://localhost:18080/maven2/</url>
    </repository>
  </distributionManagement>
  ...
</project>
    SSH（SCP）を利用する場合は、リスト4のような設定を行ってください。

    ●リスト4 配置場所の指定（SSH(SCP)を利用する場合） 
    <project>
  ...
  <distributionManagement>
    <repository>
      <id>gihyo.jp</id>
      <name>Gihyo Repository</name>
      <url>scp:http://gihyo.jp/usr/local/maven/repo</url>
    </repository>
  </distributionManagement>
  ...
</project>
  2. 認証アカウントの設定
    3. 次に、配置に必要な認証アカウントの設定を、開発者ごとの設定を記述するためのMaven 2の設定ファイル settings.xmlに対して行います。 settings.xmlはホームディレクトリ（例：C:\Document AndSettings\yamamoto）配下の「.m2」 ディレクトリにあります（まだ作成していない場合は作成してください）。
    サンプルでは、リスト5の設定を行ってください。 SSHまたはWebDAVでパスワード認証も同様です。 SSHが鍵認証の場合はリスト6のような設定を行ってください。

    ●リスト5 認証アカウントの設定（サンプルの場合） 
    <?xml version="1.0" encoding="UTF-8"?>
<settings>
  <servers>
    <server>
      <id>gihyo.jp</id>
      <username>emuko</username>
      <password>emuko</password>
    </server>
  <servers>
</settings>


    ●リスト6 認証アカウントの設定（SSHが鍵認証の場合） 
    <?xml version="1.0" encoding="UTF-8"?>
<settings>
  <servers>
    <server>
      <id>gihyo.jp</id>
      <username>ユーザ名</username>
      <privatekey>プライベートキーのパス</privatekey>
      <passphrase>鍵パスフレーズ</passphrase>
    </server>
  <servers>
</settings>


  3. mvn deployの実行
    4. 最後に、mvn deployコマンドを実行すれば、ライブラリが社内リポジトリに配置されます。
    サンプルではC:\work\5\webdb-utilsディレクトリで、mvn deployコマンドを実行してください。 実行後、Webブラウザでhttp://localhost:18080/maven2/jp/gihyo/webdb-utils/にアクセスすると、バージョン1.0.0のライブラリwebdb-utilsが配置されているのが確認できます。
    なお、Maven 2プロジェクトではないライブラリ（JARファイル）を社内リポジトリに 配置することもできます。 その場合は、コマンド「mvn deploy:deploy-file」を使用します。 必要なオプションは前章で説明したコマンド「mvn install:install-file」とほぼ同じです。

社内リポジトリにあるライブラリの使い方

社内リポジトリに登録されているライブラリを使用するには、pom.xmlに設定を追加します。
  1. リポジトリ定義の追加
    2. まずpom.xmlにリポジトリ定義を追加します。id要素およびurl要素は、リポジトリのIDとURLです。 サンプル社内リポジトリを使用するためには、リスト7の設定を行ってください。

    ●リスト7 リポジトリ定義の追加（サンプルの場合） 
    <project>
  ...
  <repositories>
    <repository>
      <id>gihyo.jp</id>
      <name>Gihyo Repository</name>
      <url>http://localhost:18080/maven2</url>
    </repository>
  </repositories>
  ...
</project>

  2. 使用するライブラリの定義
    3. あとは、普通の依存ライブラリと同様にdependencies要素に追加すればOKです。 先ほどの配置したサンプルライブラリを使用するためにはリスト8の設定を行います。

    ●リスト8 dependency定義の追加（サンプルの場合） 
    <project>
  ...
  <dependencies>
    <dependency>
      <groupId>gihyo.jp</groupId>
      <artifactId>webdb-utils</artifactId>
      <version>1.0.0</version>
    </dependency>
  </dependencies>
  ...
</project>

社内リポジトリの効能

社内リポジトリがあると、Maven 2のメリットを最大限に生かせるようになるので、細かい単位で分 割したライブラリを作りやすく・使いやすくなります。 社内の便利ライブラリをpom.xmlにdependency定義を追加するだけで利用できますので、社内にお ける「車輪の再発明」がなくなるでしょう。
また、社内で開発するライブラリにはバージョンを付けることが半強制的になりますので、きちんと したバージョン管理が行えるようにもなります。
さらに、アプリケーションの「設計」にもよい影響を与えます。「アプリケーションとライブラリ」や 「ライブラリとライブラリ」の依存関係を小さくすることができるようになるからです。 これをさらに推し進めると、できるだけ小さい責務や機能の「モジュール」に分割した設計を行うようになることでしょう。 そうなるとMavenのマルチモジュールプロジェクト（複数のサブプロジェクトからなるMavenプロジェクト）で開発したり、ライブラリ開発ではSNAPSHOTバージョン（開発中バージョン）での頻繁なリリースを行うようになったりと、リズミカルで気持ちよく開発が進められるようになります。