今回は2005年の第1回目となる。第1回目ということで，普段と趣向を変えて，Apache Software Foundationにおけるプロダクトの管理方法について紹介しよう。
共同作業のためのさまざまなサービス
一昔前と比較すると，オープンソース・ソフトウエアを開発するための環境は格段に向上した。開発者とプロジェクトのサーバーおよび開発者同士を繋ぐネットワークは速くなり，情報やリソースの入手と配布の効率は飛躍的にあがった。
また，オープンソース開発プロジェクトの運営をサポートする無償サービスも行われるようになり，誰でも簡単にオープンソースのプロダクトを開発できるようになった。SpringフレームワークやO/Rマッピング・ツールのHibernateが開発されているSourceForge.net，PicoContainerやGroovyが開発されているCodehausなどが有名だ。最近では，Sun Microsystemsがjava.netという同様のサービスを提供しはじめている。このようなサービスを利用して，多くの有益なオープンソース・プロジェクトが生み出されている。
本連載でウォッチしている Apache/Jakartaプロジェクトはご存知の通り，Apache Software Foundation（ASF）が提供するサービスを利用して開発が行われている。プロジェクト開始のための仕組みや参加方法などが他の多くのサービスとはルールこそ異なるが，開発者に対して提供している機能に大差はない。プロジェクトのポータル・サイト開設，リソース管理用のリポジトリへのネットワーク・アクセス，リリース・パッケージ配布，メーリング・リスト，バグ管理などだ。
しかし，大きく異なる機能もある。その１つがビルドを自動で定期的に行うナイトリ・ビルドだ。設定されたプロジェクトのスクリプトを定期的に実行し，ビルドやテストを自動的に実行する仕組みである。保有するプロジェクトが多いと，ビルドが長時間におよんでしまい，現実的でない処理だが，ASFは，自由にプロジェクトを開設できないため，保有するプロジェクトは他のサービスと比較すると少ない。そのため，ナイトリ・ビルドが実現できている。
もう１つの大きな違いにリソース管理システムがあげられる。ASFでは従来CVSを利用していたが，最近ではSubversionが利用されはじめている。純粋にオープンソース開発サポートサービスと，ASFのように自由に環境の運営も行うコミュニティを単純に比較する事はできないが，ASFではビルドの仕組みや管理方法の選択は比較的自由に行われている。
ナイトリ・ビルドの仕組み
まず，ナイトリ・ビルドの仕組みを紹介する。ナイトリ・ビルドはApacheで開発しているGumpというツールによって行われている。Gumpは自身をApacheの継続的インテグレーション(Continuous Integration)ツールと紹介している。Continuous Integrationはその名が示すように，XPのプラクティスに由来する。一日に何度もインテグレーションし，テストにパスするようにすることだ。
このような処理はAntのタスクを工夫することで実現する場合が多いが，Gumpはそれに替わる処理を複数のプロジェクトに跨って行うツールだ。具体的には，複数プロジェクト間の依存関係を解析し，順にビルドやテストをおこなってゆき，その結果をブラウザから参照可能な形式で出力する。ビルドの際には指定されたリポジトリよりチェックアウトを行い，最新のリソースがビルドされるようになっている。
ASFには同様の機能を提供するAlexandriaというツールがJakartaプロジェクトに存在していた。しかし，このプロジェクトの活動は既に停止しており，Obsoleteとなっている。Alexandriaのサイトでも紹介されているが，Gumpはその後継として作られたものだ。
ASF内でのGumpの利用のされかたは，ASF内で動作しているGumpが出力する様々な情報から得ることができる。ASFではBrutusというマシンでナイトリ・ビルドの処理を行っている。そして，Javaのプロダクトに対して異なるJVMでの処理を時間を空けて行い，それを日々繰り返している。Sun JVM 1.4で0:00と18:00に，Sun JVM1.5で6:00に，Sun JVM 1.4でGumpのコードの異なるケースで12:00に，Kaffe VM で６時間置きにといった具合だ(それぞれの時間はPacific Time)。それらの結果は，HTMLとして出力されブラウザから参照することができる。
[http://brutus.apache.org/gump/public/]はSun JVM 1.4 で処理を行った結果のトップページだ。ページの中盤に処理したプロジェクト数と成功率のサマリが表示されている。それによると，実に795のプロジェクト（執筆時時点）をビルドしているのが分かると思う。プロジェクトの内訳は，処理結果を示すログのページは，(http://brutus.apache.org/gump/public/buildLog.html)にある。このリストから Apache HTTP Server(http://httpd.apache.org/) を含むASF内のほぼすべてのプロジェクトのビルドを行っているのが分かると思う。
プロジェクトの依存関係から，Apache以外のプロダクトも場合によってはビルドしている。リストには，成功失敗を示すステータスがプロジェクトごとにつけられており，ビルドに失敗したプロジェクトを簡単に見つけることができる。また，失敗したプロジェクトだけをリストにしたページ(http://brutus.apache.org/gump/public/project_todos.html)も出力される。それぞれの失敗原因などの詳細はプロジェクト毎の情報ページを参照できるようになっている。
このような仕組みはオープンソース・プロダクトの開発に限らず，一般的な開発においても必要だ。通常は，Unixのcronや WindowsのATによって実現することになるが，プロジェクト間の依存解決や結果の可読性をサポートしようとすると，非常に困難な処理となる。しかし，このGumpを用いることでそれらの問題は解決されるのだ。Gumpは，XMLファイルによって処理条件を定義するようになっている。Gumpをインストールし，XMLファイルを定義することによって，前述のようなナイトリ・ビルド環境が簡単に構築できる。Gumpの利用方法は次回以降で紹介するのでご期待いただきたい。
注目ツールSubversion
ASFで利用されているもう１つの注目ツールにSubversionがある。Subversionは CVSの後継となるように設計された比較的新しいバージョン管理システムだ。SubversionはASFで開発されたプロダクトではないが，Apache/BSDスタイルのライセンスにて配布されており，比較的利用しやすくなっている。CVSと似た操作性を確保しつつCVSの持っていたさまざまな問題点を克服したツールであり，多くのオープンソース・プロジェクトがSubversionにリソースの管理を託しはじめている。
この流れはASFにも及んでおり，新しく開始したプロジェクトのみならず，今までCVSでリソース管理を行っていたプロジェクトまでもが，Subversionに移行し始めている。 現在，ASFではCVSとSubversionの２つのバージョン管理ツールを提供しており，どちらを利用するかはプロジェクトが決めている。両ツールともminotaurというマシン上でネットワークへリソースを提供しており，それぞれ，(http://cvs.apache.org/viewcvs.cgi)，(https://svn.apache.org/repos/asf/)から利用しているプロジェクトを参照することができる。前述の Gumpやjakarta-Velocity，struts，geronimoなどが Subversionで管理されているのがおわかり頂けると思う。
前述のGumpは，プロジェクトのリソースの管理先がCVSでもSubversionでもよいように作られており，簡単な定義の違いで両者の操作上の差異を吸収し最新のリソースをチェック・アウトできるようになっている。次回は，このSubversionとGumpそしてそれらの連携方法について紹介してゆく。
■著者紹介
黒住幸光（くろずみ ゆきみつ）氏
株式会社アークシステム システム構築スペシャリスト。1995年，スーパー・コンピュータ向け言語処理環境の研究中に，生まれて間もないJavaと出会う。のちにJavaに専念するため転職を決意。現在，株式会社アークシステムにてオープンソース・ソフトウエアを用いたWWWシステムの構築，コンサルティングを行うかたわら，雑誌への執筆，StrutsユーザーMLの管理，Ja-JakartaプロジェクトTurbine翻訳の取りまとめなど幅広く活動中。著書に「Apache Strutsハンドブック」（発行：ソフトバンクパブリッシング）がある。メール・アドレスは，yukimi_2@yahooo.co.jp
