去る11月11日にリクルートメディアテクノロジーラボの「カフェ」でTokyo GTUG(Google Technology User Group) #4のイベントが開催されました。テーマはOpenSocialで、今回は「OpenSocialのアーキテクチャ」というテーマで講演させて頂きましたので、スライドを公開します。

Mac OS XをSnow LeopardにしたらPHPが5.3になってて、PartuzaやShindigを使うのにentropyを入れなくても済んで、とても素敵です。

しかし同環境でMySQLを使うのに、ちょっとごにょごにょしなければならなかったのでメモを残しておきます。(2009年9月現在の情報です)

MySQLをダウンロード

MySQLのバイナリをこちらからダウンロードします。このページの下の方にあるMac OS X(package format)の中から、(Snow Leopardは10.6ですが)Mac OS 10.5(x86_64)を選びます。

MySQLをインストール

インストールはGUIでできます。環境設定項目とスタートアップアイテムもインストールしちゃいます。パスも切っておきましょう。

~/.bash_profileを作るか、既にあれば下記を追記します。

PATH=$PATH:/usr/local/mysql/bin
export PATH

さらに

> source ~/.bash_profile

とかやれば、即時反映できます。

ごにょごにょする

ここからがポイント。

>  cd /usr/local/mysql
>  sudo ./script/mysql_install_db

そんで

>  sudo cp /etc/php.ini.default /etc/php/ini
>  sudo vim /etc/php.ini

とかやって、

mysqli.default_socket = /var/mysql/mysql.sock

の部分を

mysqli.default_socket = /tmp/mysql.sock

に書き換えます。

これで、MySQLを立ち上げ直せば、オッケー。環境設定からMySQLをスタートすれば、PHPでMySQLが使えるようになったはず。

追記

ちなみにこの設定はPartuzaの動作を確認したのみですので、他のことをやる場合はもう少しいじる必要があると思います。

「ウェブはソーシャルであるべきだ」。これは今の会社に
入社した2005年くらいからずっと訴えてきたことです。ソーシャルグラフをプラットフォーム化することで実現できることがたくさんあります。まずはポータルサイト全体をソーシャル化することを目標にし、作り上げたのがgooホームでした。

将来の構想はその時点で既にあって、いずれはポータル外のサイトとも接続して、インターネット全体がソーシャルグラフで繋がることをイメージしていました。そんな時に登場したのがFacebookです。

Facebookがやろうとしていたことは、SNSの中にサービスを取り込むという、僕の考えとは真逆でしたが、結果的にやろうとしていたことは似たようなもので、先に実現されたことにくやしい思いをました。そしてOpenSocialが登場します。

OpenSocialは仕様を民主的に決めて行くオープンなスタイルでした。オープン性のメリットは計り知れません。2つ以上のシステムを繋ぐのに、仕様から作るよりも、既に決まり事があれば話が早いのは火を見るよりも明らかです。技術的工夫もさることながら、コミュニケーションコストは大幅に削減できます。

さらに、オープンな仕様であればそれを使ったプロダクトが生まれやすくもなります。OpenSocial周りでも既に、よういちろうさんのOpenSocial Development EnvironmentやOpenSocial Client Library、OAuth関連ライブラリ、そして僕の作ったOpenSocial Signed Request Libraryなど、様々なオープンソースプロダクトが生まれ、後発の生産性を上げています。

そんなOpenSocial関連プロダクトの中心となるのが、OpenSocialコンテナのリファレンス実装であるShindigです。

僕がOpenSocialの既存仕様を学ぶ上で紐解いたのものこのShindigでした。当時はまだ日本でほとんど手をつけている人がいなかったため、API Expertとして声をかけて頂いたのも、Shindigに関する情報をこのブログで公開していたためです。

その後実際にgooホームでディプロイするに辺り、様々なパッチを書き、Shindigの開発チーム提供してきました。(もちろん、OpenSocialの仕様自体にも口を出してきましたが。)そうこうしているうちに、1年半ほどが経過し・・・

このたび、Shindigのコミッターになりました。

PHP版ShindigのメインコミッターであるChris Chabot氏とは、PHP版の最初のコミット前から連絡を取り、昨年のGoogle IOでも直接お会いし、その後もメッセンジャーで話したりしてきましたが、そのChrisにShindigのコミッターに推薦して頂いたのです。

Apache Software Foundationでコミッターになるには、既存コミッターの投票が必要らしいのですが、これまでの貢献を認めてもらい、承認して頂きました。

PHP版Shindigは今や、全世界述べ5億人(!)が26以上のSNSで使っているといいます。にも関わらずフィードバックされていたパッチはそれほど多くなく、自分がやってきたことは貴重だったようです。

本来僕にとってOpenSocialというのは理想のSocialWebを実現するための道具に過ぎないのですが、少なくとも日本では実質的なデファクトであり、mixiやgooホームで使われているShindigというプロダクトは、その根幹を支えるものです。

今後はShindigのコミッターとしても、日本のSocialWebを作り上げ、支えて行ければと思います。

OpenSocialと関わるには

• コンテナになる
• ガジェットを開発する
• RESTを使ったクライアントサービスを作る

といった選択肢が考えられますが、そのいずれを選択するにしても、アーキテクチャについて知っておくことはとても重要です。特にガジェットを開発するに当たっては、アーキテクチャを知っていることでより開発しやすい場面が多々あります。

そこで今回は、OpenSocialに対応するコンテナのほとんどで利用されているオープンソースのリファレンス実装、Shindigのアーキテクチャについて解説したいと思います。

ガジェットとSNSの関係

iGoogle(既にShindigが利用されている)ではどうやって第三者の作ったガジェットを表示しているかご存知でしたか？実は、別ドメイン(iGoogleならgmodules.com)上にレンダリングしたガジェットを、iframe内に表示しているのです。

理由は、同ドメイン上に第三者の書いたJavaScriptを置くことは、セキュリティ上危険だからです。詳しくは以前Cajaについて解説した記事がありますので、そちらをご覧ください。

APIはどこにあるか

OpenSocialにはPeople, Group, Activity, Persistentの4つのソーシャルなAPIが用意されていますが、それぞれRESTfulによるJSON, XML, AtomPub形式と、RPCによるJSON形式が用意されています。ShindigのJavaScript APIでは、この中でもRPCによるJSON形式が使用されています。

先ほど2つのドメインについて説明しましたが、JavaScriptのAPIということはAjaxなので、当然同じドメインということで、エンドポイントはShindigのドメイン上に存在します。

ガジェット表示の流れ

基本的な構造が分かったところで、実際にガジェットを表示するまでの流れを見てみましょう。

どのガジェットを表示するのか

ガジェットを表示するためには、まずガジェットを表示したいというユーザーの意思が必要です。これはiGoogleであれば、ガジェットディレクトリから好きなガジェットを選び、自分のページを表示する、というサービス側での作業によって行われます。表示したいガジェットが分かったところで、サービス側もガジェットを表示するためのiframeを表示する必要があるため、ガジェットに関する情報を収集します。これはShindigのmetadata APIを使って行われます。

metadataの取得

metadata APIのリクエストを取得したShindigは、キャッシュを参照します。キャッシュにガジェットの情報が残っていない場合は、サービスからのリクエストに基づいてガジェットXMLを取得し、解析します。

iframeのレンダリング

ガジェットに関する情報を取得したサービスは、ガジェットを表示するためiframeをレンダリングします。これにより、iframe内にガジェットを表示するためのリクエストがブラウザからShindigに投げられます。

基本的にガジェットXMLに記述されたContentsの内容はそのまま表示されますが：

• 指定されたガジェットのfeature(tabやminimessageなど、ガジェットが持つ機能セット)のJavaScriptがHTMLに追記される。
• 設定によってはJavaScript、CSS、画像などのあらゆる外部コンテンツがShindig上にキャッシュして呼び出される。

という点は覚えておいて損はないでしょう。

これでガジェットの表示は完了です。Firebugなどを使ってAPIを試してみれば、Shindigにリクエストが飛んでいることが分かると思います。

外部サーバーを使うAPI

外部サーバーを使う際、JavaScript APIとしてgadgets.io.makeRequestが使用されます。コンテンツタイプとしてFEEDを選択すると、RSSやRDF、Atomを共通のフォーマットで返してくれたり、JSONを選択すると、データが返ってきた時点ですぐにJSONオブジェクトとして扱えるようになっています。

また、セキュリティ面でもいくつかの選択肢が用意されています。

• 通常のリクエスト
• Signed Request
• OAuth

通常のリクエストは、特に認証等のかかっていないAPIに対して行われるものです。Signed Requestとは、OAuth Consumer Requestを指しており、これを利用することで、外部サーバーはガジェットからのリクエストのみを扱うことができるようになります。OAuthはOAuth Coreを指しており、外部サーバーはガジェットからのリクエストであることだけでなく、誰からのリクエストなのかをセキュアなクレデンシャルで認証した上で扱うことができるようになります。

OAuthについてはこの辺りかこの辺りを参考にしてください。

ここで注意しなければならないのが、すべてShindigのproxyを介して行われるということです。先ほど書いた通り、ここでもGETリクエストには強力なキャッシュ機能が利用されるため、若干注意が必要な場合があります。キャッシュについては次回以降まとめて記事にしたいと思います。

OpenSocialのコンテナと言えばShindigですが、PHP版は既にOpenSocial v0.7への対応を完了しています。Partuza!はPHP版Shindigの開発者であるChris Chabot氏がオープンソースで開発したShindig対応SNSです。

Shindigがコンテナなのに、じゃあPartuza!は何をするの？と思われるかもしれません。今回はインストール方法と、Shindigとの関係について解説します。

Partuza!をインストールする

Shindigのインストール方法は以前解説しましたので、ここでは割愛します。仮に、Shindigが~/shindig配下にインストールされ、http://localhost:8080/gadgets/…でアクセスできるものとします。

まず、環境としてApache、PHP5(要mcrypt)、MySQL5が必須となります。

レポジトリからチェックアウト

Google CodeのレポジトリからSVNでチェックアウトします。

> svn checkout http://partuza.googlecode.com/svn/trunk/ ~/partuza

データベースを用意

適当なデータベース名、ユーザー名、パスワードで空のDBを作ってください。ひとまずここではそれぞれ、partuza、root、パスワードなしとします。この状態で、~/partuza/partuza.sqlをダンプします。

> mysql -u root partuza < partuza.sql

DocumentRootを設定

Apacheの設定(httpd.conf)でDocumentRootを~/partuza/htmlに設定し、http://localhost/でアクセスできるようにします。もちろん、Shindigとは別ドメインを用意する必要がありますので、バーチャルホストを使う等してください。

設定ファイルを修正

~/partuza/html/config.phpを編集します。ここでは先程作成したデータベース関連の情報とガジェットサーバーのルートURL(gadget_server)を設定します。ガジェットサーバーのURLが、ここではShindigのURLとなりますので、http://localhost:8080/になります。

データベースハンドラをコピー

~/partuza/Shindig/PartuzaDbFetcher.phpと~/partuza/Shindig/PartuzaHandler.phpを~/shindig/php/src/socialにコピーします。

> cp ~/partuza/Shindig/Partuza* ~/shindig/php/src/social

Shindigのデータベース設定を修正

~/shindig/php/src/social/PartuzaDbFetcher.phpにもデータベース関連の情報があるので修正します。加えてShindigがデータベースハンドラを利用するよう、~/shindig/php/config.phpも修正します。ここでは、”handlers => PartuzaHandler”としてください。

これで一通りの準備は完了。http://localhost/にアクセスしてウェルカム画面が出れば成功です。このまま登録し、Orkutライクな一般的なSNSとして利用することができます。

Partuza!とShindigの関係

OpenSocialのガジェットがiframeを介して表示されていることは以前も解説しましたが、簡単に言ってしまえば、iframeの手前がPartuza、後ろがShindigになります。Shindigでは以前から下記のURLにアクセスすることで簡易的なHTMLからOpenSocialぽい表示を行うことはできていましたが、Partuzaを使うことで完全なSNSとなります。

とはいえ、PartuzaHandlerを指定したところからも想像できるように、データベースは共有されます。なお、Chris Chabot氏のサイトで実際に動いているものを確認することができます。

Partuza!を使うことで、どうすればShindigをSNSに組み込むことができるかの解析をすることができるだけでなく、そのままちょっとしたSNSを開発することもできてしまいます。ぜひお試しください。

以前インストール方法をご紹介した(Java版、PHP版)Shindigですが、ようやくPHP版も使えるレベルになってきましたので、ソースを読み解いてみました。なお、Java版の方が実装は進んでいますが、今回はPHP版に限った話ですのでご注意ください。

Shindigとは何なのか

そもそも、の話です。

Shindigはひとことで言うと「OpenSocialコンテナのサンプル実装」です。これをダウンロードして動かすだけで、iGoogleガジェットとOpenSocialガジェットの動作テストを行うことができます。実際はOpenSocialを広く普及させるよう、数多あるSNSがShindigを参考に、もしくは流用してOpenSocialに対応することを目的にしています。

• Shindig - an Apache incubator project for OpenSocial and gadgets
• メーリングリスト
• レポジトリ

主なディレクトリ構成

• config: コンテナ設定
• features: 各種機能セット(JavaScriptコード)
• java: Javaソースコード
• javascript: HTML, JavaScriptコード
• php: PHPソースコード

ディレクトリ解説

config

container.jsというファイルがコンテナのデフォルト設定となり、プロキシやOpenSocial APIのパス等の設定を行います。設定を変更したい場合はこのディレクトリにファイルを追加して、必要な部分のみをJSON形式で追記すれば、デフォルト設定が引き継がれます。なお、JSON形式なのは、PHPやJavaだけでなく、他の言語からも読み込むことを想定しているためと思われます。(Perl版やRuby版のShindigも開発される予定だそうです。)

features

ガジェットXMLに<Require features=”">という形式で記述される機能(features)をセットとして読み込みます。featuresディレクトリ内は機能セットごとにさらにディレクトリに分けられていて、各ディレクトリにあるfeatures.xmlファイルで必要なJavaScriptライブラリセットが指定されています。

php

PHPのソースコードはJava版を参考にしているためか、あまりPHPらしくない実装になっています。

まずMVC形式を取っていません。オブジェクトの分け方は色々な方法がありますが、ウェブアプリケーション的なものと言うよりは、Java的な方法で(?)機能や設定ごとに、非常に細かく分けられています。メンバ変数にいちいちget〜やset〜メソッドを用意しているのもJavaっぽい。

PHPへのリクエストはリライトされ(.htaccessファイルで指定)、すべてindex.phpに読み込まれます。index.phpはリクエストのパラメータに応じて処理を6種類のサーブレットに振り分けます。

• 静的ファイル(/gadgets/files)
• JavaScript(/gadgets/js)
• プロキシ(/gadgets/proxy)
• ガジェット(/gadgets/ifr)
• メタデータ(/gadgets/metadata)
• OpenSocial API(/social/data)

クラスのインクルードは__autoloadが使用されているため、ほとんど書かれていません。

config.phpには各種ファイルへのパスなど、設定が記述されています。(config/container.jsとは別物です)

なお、Shindigはデータベースを使っていないので、キャッシュは/tmpディレクトリ、設定はcookie、友達リストは静的XMLファイルでそれぞれ管理されます。

まとめ

ソースコードは一見シンプルですが、かなり複雑です。Java的な実装方法に加え、他言語版Shindigとの設定等の共有を想定した汎用化など、オプティマイズする余地はかなりありそう。PHP版Shindigを既存フレームワークに取り込むのは難しくはありませんが、あくまでも参考にする程度にした方がいいと思われます。

なお、今のところOpenSocialバージョン0.7対応ですが、まだまだバグも存在しています。バージョン0.8の機能仕様が出揃ってきたところですが、Shindigでの対応は時間差が出そう。

OpenSocial APIは実装されていますが、ShindigでOpenSocial機能が使えるようになったというには、まだまだ足りない感じ。あとはOAuthとか、RESTful APIとか、、、。

OpenSocial周りの調査をしていると、Cajaという言葉に遭遇します。セキュアなJavaScriptを実現するもの、ということだけ分かっていたのですが、詳細を調べてみました。

クロスサイトスクリプティングとブログパーツ

gooやlivedoor、fc2などのホスティングを含めたブログサービスを使ったことのある方はご存知と思いますが、サービスによってブログパーツが貼れるもの、貼れないもの、一部だけ許可しているものがあります。なぜでしょうか？

Cookieには同一ドメインから実行されたスクリプトしか参照できないという特徴があります。これを利用して、Cookieをセッション情報や閲覧履歴の保存場所として活用しているサービスは少なくありません。上記ブログサービスがブログパーツを許可しないのは、これらの情報を悪意のあるJavaScriptから守るためです。逆に言うと、同一ドメイン上でJavaScriptが実行できれば、そのセッション情報や閲覧履歴を盗むことができてしまいます。これをXSS(クロスサイトスクリプティング)と言います。

XSSが発生するのは、投稿フォームを使って、そのドメイン上のページにJavaScriptを埋め込み、実行できるケースが挙げられますが、ブログパーツが貼れること自体もJavaScriptが埋め込めるという意味では同じであり、まともに作られたサイトであれば、まずこういったことは出来ません。

とはいえ、実際にブログパーツを貼付けることができるブログは存在しますし、セキュリティの問題を回避しつつこれを実現するためのアプローチがいくつか存在します。

JavaScriptを貼付けるためのアプローチ

ドメインを分ける

ブログを表示するドメインをセッション情報等のクリティカルなCookieを保存していないものにしてしまいます。盗むものがなければ、泥棒が入ったところで何も困ることはありません。このアプローチをとっているものにはlivedoorブログが挙げられます。

安全性の確認できたJavaScriptのみ許可する

サービス提供者が安全なブログパーツのリストを作り、ブログ管理者がそこから選ぶ、というアプローチです。ブログパーツの選択肢が狭くなるためユーザーには好まれませんが、全く貼れないよりはよいはず。gooブログやはてなダイアリがこのアプローチをとっています。

iframeで表示する

iframe内に別ドメインで表示してしまえば、上記「ドメインを分ける」と同様に扱うことができます。このアプローチを取っているものにiGoogleが挙げられます。iGoogleはブログではありませんが、ブログパーツ=ガジェットと捉えれば同じ問題を扱っていると言えます。

JavaScriptの危険な部分を無力化する

サーバーがJavaScriptを出力する前に危険な部分を書き換え、無力化してしまいます。このアプローチをとっているブログがあるか知りませんが、やり方としては誰でも思いつくのではないでしょうか。ただ、これを実現するためには膨大な労力と知識が必要となります。これがオープンソースで存在しているとすれば、どんなに素晴らしいでしょう。そして、これを実現することができるのが今回紹介する、Cajaです。

Cajaで実現できること

Cajaはカハと読みます。CajaはGoogleのオープンソースプロジェクトの名前で、これを使うことで、同一ドメイン上のページに安全に外部のJavaScriptを貼付けることが可能になります。

Caja紹介(日本語訳)

開発に当たってCajaを使って防がれるべきとされた攻撃方法の一覧

どこでCajaを使うのか

CajaはOpenSocialコンテナ上での利用を想定して作られているようです。Caja紹介(日本語訳)の説明も、Shindigでアプリケーションを利用することが前提となっており、Cajaを使ってガジェットをインラインで表示した方がパフォーマンスが向上する旨が記載されています。

Cajaの形態

実はここがまだ調べきれていない部分なのですが、どうやらJavaによるサーバーサイドでのリライトと、JavaScriptのライブラリで構成されている、ぽいです。この辺はもう少し調べる必要がありそうです。

何か他に情報をお持ちの方がいらっしゃいましたらぜひ、教えてください。

先日のGoogleディベロッパー交流会でShindigのphp版が公開されていることを知り、試してみました。

Shindigをチェックアウトする

> svn co http://svn.apache.org/repos/asf/incubator/shindig/trunk .

Shindigのソースがチェックアウトされます。(今回試したリビジョンは637739)

> ln -s ~/Development/Shindig/php/gadgets /Library/WebServer/Documents/gadgets

これでローカルホスト上で見れるはず。ブラウザに下記のURLを入力します。

http://localhost/gadgets/ifr?url=http://www.labpixies.com/campaigns/todo/todo.xml

見れません、、、

httpd.confを修正

どうやら、Mac OS X(Leopard)のhttpd.confのデフォルト 設定が邪魔している模様。

/etc/apache2/httpd.conf

を書き換えます。/etc/httpd/httpd.confではないことに注意。(Tigerはこれだった)

<Directory "/Library/WebServer/Documents">

内の

AllowOverride None

を

AllowOverride All

に変更します。これでいけるはず。。。

できた！これで、色々いじれますよ・・・

表参道のダイヤモンドホールで行われたGoogleディベロッパー交流会に参加してきました。今回はOpenSocialがテーマということで、ドンピシャ。 色々な疑問を解決することが出来ました。

OpenSocialアプリケーション(ガジェット)はSNS間を持ち回れない？

とても基本的な疑問ですが、。OpenSocialは異なるSNS間でAPIを共通化することで、アプリケーション開発者の負担を軽くすることが目的のため、互換性は保証されるものと考えていましたが、どうもそういう訳でもないらしい。なぜなら、OpenSocialはアプリケーションを乗せるもの(OrkutではGoogle Gadget)について規定していないから。

OpenSocialの仕様書を見ると、サンプルコードはすべてGoogle Gadgetを想定して書かれていますが、実際の仕様にGoogle Gadgetが要件であるとは書いていません。つまり、別にOpera WidgetだろうとYahoo! WidgetだろうとDashboard Widgetだろうと、乗せられるところに乗せてよい訳です。そこでこの辺りをはっきりさせるため、プレゼンをしてくれたクリスさん(ラストネームは忘れた)に聞いてみました。

• ガジェットはGoogle Gadgetのみを想定している訳ではない。
• MySpaceAppやhi5、OrkutはGoogle Gadget形式で提供される(未確認)
• アプリケーションは基本的にSNS間で共有できるが、拡張機能に対応していると、別のSNSでは動かない可能性もある。

僕の拙い英語力だと、なんだか釈然としない答えしか得られませんでした。なんだかまだもやもや感が残ってますが、個人的にこう思ってます。

• ガジェットはGoogle Gadgetである必要はない
• アプリケーション開発者は、コア機能は共通かできるが、ガジェット部分についてはSNSごとに用意する必要がある。

OpenSocialはRESTful APIの仕様が出るまで役に立たない?

OpenSocialはSNSから友達の情報を取得できることが目玉な訳ですが、当然認証認可が必要になります。JavaScriptのAPIでは、単純にnewDateRequestを使って簡単に取得できるように書いてはありますが、コンテナ側の実装はそう単純ではありません。

Google Gadgetを前提とした場合、コンテンツタイプとして2つの選択肢があります。1つはGadget XML中にHTMLも記述するhtmlモード。もうひとつはGadget XML中にリモートURLを記述するurlモードです。htmlモードはGoogleの管理するgmodules.comというドメイン上で動作しますが、urlモードの場合は、サードパーティーの管理する全く別のドメインで動作することになります。察しの良い人はこの時点で気付くかと思います。

リモートサーバーからOpenSocialのSNS情報にアクセスするには、そのリモートサーバーのプロキシを介して、SNSのRESTful APIを叩く以外、方法がない

これは単純にAjaxがドメイン超えできないということに起因していますが、とても重要なこと。RESTful APIがまだ正式に用意されていないOpenSocialなだけに、これがないと使い物にならないんじゃないの？MySpaceのRESTful APIってなによ！？ OrkutのiLikeアプリってリモートじゃね！？という疑問が募ってしまったのでした。(あれ？AjaxってJavaScript自体の置いてあるドメインだったら直接リクエスト投げられるのか!?)

Shindigについて

先日インストールしたShindigですが、まだJavaしか対応していないものだとばかり思い込んでました。そしたら、Javaよりも実装は遅れているけど、PHPもあるというじゃないですか！！早速帰ってコードを見てみると、、、確かにありました。お作法がJavaっぽいのでアレレな感じですけど、PHPメインの僕にとってはありがたい発見。

他にも

• リクルートの方が作ったというShindigを使ったOpenSocial対応のドコイクβサービス
• こみゅすけのOrkutアプリ版
• OpenSocialアプリコーディング環境CodeRunner(Orkut上のアプリ)
• Orkut上にOpenSocial Japanというコミュニティ

などなど、、、子供がうるさいので今日はこの辺で。

参考資料 :Shindig – an Apache incubator project for OpenSocial and gadgets

予めMavenのインストールが必要

Maven – Download Maven 2.0.8 からダウンロード。特にインストール作業は必要なく、適当なところに置いといて、パスを切る必要あり。ひとまず

> ~/Development/apache-maven-2.0.8

に置いておこう。環境変数も設定しておく。

> export JAVA_HOME='/System/Library/Frameworks/JavaVM.framework/Versions/A'> export PATH=$PATH:/Users/ekita/Development/apache-maven-2.0.8/bin

・・・とか思ったら、Maven入ってるじゃん！なにこれOS X!!

Shindigを設置

> mkdir Shindig

レポジトリからShindigのソースをチェックアウトする

> svn co http://svn.apache.org/repos/asf/incubator/shindig/trunk .

ビルドする

> cd ~/Development/Shindig/java/gadgets> mvn package

勝手に色々ダウンロードしてよしなにしてくれるみたい。

Shindigを起動してみる

> mvn jetty:run-war

で動くらしいのだが、、、

[INFO] Scanning for projects...[INFO] Searching repository for plugin with prefix: 'jetty'.[INFO] org.apache.maven.plugins: checking for updates from central[INFO] org.codehaus.mojo: checking for updates from central[INFO] artifact org.apache.maven.plugins:maven-jetty-plugin: checking for updates from central[INFO] ------------------------------------------------------------------------[ERROR] BUILD ERROR[INFO] ------------------------------------------------------------------------[INFO] The plugin 'org.apache.maven.plugins:maven-jetty-plugin' does not exist or no valid version could be found[INFO] ------------------------------------------------------------------------[INFO] For more information, run Maven with the -e switch[INFO] ------------------------------------------------------------------------[INFO] Total time: 2 seconds[INFO] Finished at: Wed Mar 12 16:18:09 JST 2008[INFO] Final Memory: 1M/2M[INFO] ------------------------------------------------------------------------

うまく動かない、、、 どうやらJettyというのが必要らしい。

Jettyを動かす

Javaサーバーはさっぱりなのでよくわからないけど、とりあえずjetty-6.1.8をダウンロードし、~/Development配下に移動。

> cd ~/Development/jetty-6.1.8

> java -jar start.jar

とかやってみる。どうやらこれでjettyというウェブサーバーが動いてることになってるらしい(多分Apacheも動いてる必要アリ)そこで、先ほどビルドしたShindigのwarファイルをシンボリックリンクして

> ln -s ~/Development/Shindig/java/gadgets/target/gadgets.war ~/Development/jetty-6.1.8/webapps/gadgets.war

アクセスしてみると、、、

http://localhost:8080/gadgets/files/samplecontainer/samplecontainer.html

動いた〜！！今日はここまで。