モジュールの集中ライブラリ
Yoshiori Shoji
ネタを投下したいと思います。
矢野さんの日記なのですが
- モジュールの集中ライブラリが必要だ
-- http://d.hatena.ne.jp/t_yano/20060720/1153414595
- 最新バージョンの自動検知はできるかな？
-- http://d.hatena.ne.jp/t_yano/20060731/1154363251
について自分も同じようなことを考えていたのですが、
ぜんぜん頭がまとまらないので
せっかくなのでみんなで考えられればなぁと思って書いてみます。
まず最初に矢野さんの言葉を借りると
「 Java にも CPAN のようなものが必要だ。モジュールとそのコード・スナップと解説がひとまとめになったようなものを大量に保管したところが。」
ということです。
BSD でいう ports、Perl でいう CPAN、PHP でいう PEAR、Ruby でいう GEMS、debian でいう
apt、gentoo でいう emerge・・・
Java にもそういうものがあったらなという認識でいるのですがあってますでしょうか？
一応、自分の頭の中で出てきた案を書いてみたいと思います。
間違っているところや勘違いも多いと思うので
突っ込み大歓迎です。
１、本当に CPAN みたいに使えるようにする。
２、maven-repository を集める感覚
それぞれもうちょっと詳細に・・・
１、本当に CPAN みたいに使えるようにする。
多分（俺の認識の中では）、矢野さんはこちらよりの方向で考えてるのかなと・・・
java module モジュール名
とコマンドを打つと
$JRE_HOME/lib/ext
あたりにjarをダウンロードしてきてくれる。
利点:
楽(毎回 org.apache.commons.lang とか入れなくて普通に使える)
なんとなく「おらわくわくしてきた by 矢野さん」感がある。
欠点:
先人の道（ CPAN など）があるとはいえ仕様を一から起こすのは大変。
サーバデプロイ時や配布時に関連モジュールを集めるのが大変。(でも、これは仕様で固められるかな？)
２、maven-repository を集める感覚
maven-proxy と OZACC さんの作られた「Maven Repo Search」を合わせて
さらに登録登録用のインターフェースも作る。
利点:
ドキュメントやコード、バージョン管理、依存関係なども maven2 の仕様で完結できる
今ある資産を最大限活用できそうなので 登録画面に集中できる。
(矢野さん提案のタグ管理など)
欠点:
良くも悪くも maven の仕様に依存しすぎ。(急に仕様変わったら大変)
プロジェクトごとに pom.xml 書くのがメンドクサイ
こんな感じでしょうか？
さらに蛇足的な補足として
１の利点である「おらわくわくしてきた by 矢野さん」感ってすごく大事だと思っています。
なんというか「ドキュメントどさっ」で掘り進めて良く感覚の Java で
横に繋げて作れるようになるようなそんなワクワク感があります。
あと、classpath の概念にはあえて触れずに置きました。
そこに縛られちゃうとどうしても maven の仕様になって来ちゃいますし、
逆にそこを壊せる考えがあったら是非聞いてみたいなとと言うのが主な理由です。
(そういう意味でクラスローダの考えをいったん壊してホットデプロイを作っちゃった
ひがさんと seaser の方々はすごいなぁと思ってます。)
いきなり長文ですいません。
ホントは考えがまとまったら日記に書こうと思っていたので
こんなに長くなっちゃいました^^;
Naoyuki Kakuda
> BSD でいう ports、Perl でいう CPAN、PHP でいう PEAR、Ruby でいう GEMS、debian でいう
> apt、gentoo でいう emerge・・・
> Java にもそういうものがあったらなという認識でいるのですがあってますでしょうか？
RakeとRuby Gemsを使ったJavaビルドツール「Raven」にてそれっぽい動きがあります。
既に1万以上ものライブラリが登録されているようです。
http://gems.rubyraven.org/
--
角田 直行 <kak...@gmail.com>
http://secure.ddo.jp/~kaku/tdiary/
Tsutomu Yano
なんだか一本釣りされてしまいました（笑）
じゃあ私もちょっと長く書きます。
そうですね、ヨシオリさんの言う通り私が想定していたのはPerl
のCPANです。
portsやaptもまあ想定はしていたんですけど、CPANを一番
想定してました。
# なんかRubyGEMSができる前夜にもいまやってるような
# 「なんでRubyにはCPANがないの」というやりとりがあっ
たそうです...
実はコマンドによるダウンロードという部分はCPANのもつ検索性に
比べると私の中では優先順位は低いんですよ。それよりも検索。
CPANの
ウェブページで「RSS」と打つだけでずらーっとライブラリが表
示されて、
ひとつずつクリックしていくと中には簡単な使い方（スナップ）が書か
れてて
そのライブラリの特徴がパっとわかる。
ここが一番うらやましい。
Mavenがあっても必要十分じゃないのはそこなんですよね。
ダウンロードについてはlib/extは考えてなかったですね
(^^; あそこにいれると、
あとで入れてるのを忘れて大変な目に遭ったりするので。
そうですね、妄想してたのは、まずjava import hogeとやると、
どっかの
ロケーターサーバからhogeの場所を取得して、さらにそれをダウ
ンロードして、
ローカルリポジトリに格納する。もちろん依存jarもすべて取得
してくれる。
ただこれはあくまでローカルリポジトリに入るんであって、プロジェク
トに入る
わけじゃないです。
次にjava module hoge lib/ とかすると、ローカルリポジトリか
らライブラリと
その依存ライブラリ(jar)を全部とってきて、lib/の下に
いれてくれる。
そんなのを考えてました。でもjar単体でライブラリを格納して
いるところなん
て珍しいので、実際には中央リポジトリが必要だろうなあと思います。
あと私はgemやdebのような内部に依存情報を持ったパッ
ケージファイルを考えてなくて、
依存情報は別の情報としてサーバーにあればいいと思ってました。java
import時にローカル
リポジトリに複写されるって感じで。ライブラリ自体はあくまで
jarとして提供する
イメージです。別に分けるのは、あとで書くように「ページで編集でき
るようにするため」
でもあります。
そして検索性。
まず各ライブラリの説明ページを作らないといけないですよね。そして
上記の依存
情報もここで入力してもらう。その内容がリモートリポジトリに反映さ
れる。現在の
jarダウンロード・パスもここで書く。これがまず一つ。提供側の作業
ですね。
gemを作る代わりにページを作るわけです。当然定型フォーマットが
あって、そこ
にはコードスナップも入れる。
次に検索。ここではてなっぽいタグつけを考えてました。モジュールシ
ステムを使いたい
人はユーザー登録が必要だとして、ユーザーは自分のブックマークペー
ジを持ってる。
そして、ソーシャル・ブックマークを使う時のように、各ライブラリ
ページにタグを
つけてどんどんブックマークしていく。各人がそれぞれ自分の感覚で、
ライブラリに
タグ付けしていく。
このタグの蓄積が検索性を高めていくって感じでしょうか。
あとは編集。パッケージファイルと違ってページは（画面さえあれば）
誰でも修正
できるというのが利点でして、Wiki的に変更出来る想定です。こ
こでユーザー間の
承認機能があったら面白いなあとか妄想してました。
あるライブラリを「Watch」登録しておくと、ライブラリ・ペー
ジに修正があったら
メールで変更が通知される。Watcherは変更を「承認」または
「拒否」できる。拒否の
時には理由を書かないといけないって感じで。
一定期間（24時間とか）で承認数が拒否数を上回ってたら変更が
反映される....とか。
もちろん、多数決で承認されたあとに、拒否理由を反映するのも自由。
その場合も
同じフェーズをふむって感じで。
もちろん誰も承認も拒否もしなかったら困るので、その場合は自動的に
承認されたと
見なされるって感じですかね。
まあWikipedia的に変更即反映で変更の応酬って手もあるんです
けど。
で最初に書いたように私の中ではダウンロードコマンドよりも検索性の
確保の方が
重要度が高くて、「ダウンロードはhttp://hoge.com」とか書い
てても、検索できて
コードスナップが見られるだけでもずいぶん違うだろうなあと思います。
と、妄想を吐露してみました。
---------------------------------------------------
矢野 勉（やの つとむ）
電子メール:benbrand_at_mac.com
---------------------------------------------------
Yoshiori Shoji
一本釣りしたヨシオリです。
（ちょうど昨日、櫻庭さんにお会いする機会があったので
矢野さんが手ぐすね引いて待ってますとさらに釣っておきました。*一部誇張）
矢野さんに追従して俺もさらに妄想をつらつらと・・・
なぜ maven2 のレポジトリを使うような方向で考えたかというと
やっぱりプロジェクト管理として Maven2 は良くできていると感じる部分が多いので
なるべく利用できないかなと考えてました。
(もっと良いツールがあったら乗り換えるのも有りですが)
ただ、
>Mavenがあっても必要十分じゃないのはそこなんですよね。
ここに凄く共感してまして・・・
あのディレクトリどばっって感じが美しくないですよね^^;
後ほど URL 貼っておきますが gentoo-portage も
素晴らしいです。
>あと私はgemやdebのような内部に依存情報を持ったパッ
>ケージファイルを考えてなくて、依存情報は別の情報としてサーバーにあればいいと思ってました。
この辺は現在の Mavens2 のリポジトリでも対応できていそうだなと。
>次にjava module hoge lib/ とかすると、ローカルリポジトリか
>らライブラリと
>その依存ライブラリ(jar)を全部とってきて、lib/の下に
>いれてくれる。
これも Maven2 で逆にローカルのリポジトリに classpath 貼るという形で
実現されているなと。
>まず各ライブラリの説明ページを作らないといけないですよね。そして
>上記の依存
>情報もここで入力してもらう。その内容がリモートリポジトリに反映さ
>れる。現在の
>jarダウンロード・パスもここで書く。これがまず一つ。提供側の作業
>ですね。
これも Maven2 で
mvn deploy
コマンド一発で出来ますし
簡単なドキュメントも
mvn site-deploy
で出来るかなと。
ただ、ソースも欲しいとか色々あるので
もうそれように hoge-deploy みたいなプラグインつくちゃう方が
現実的かなとか。
そうするとモジュール提供側の手間も省けますし・・・
で、
その集中管理しているところに行くと
依存関係もソースも Javadoc も全部見れるとか
すっげー嬉しい！！
で、矢野さんの言われてるような感じで
モジュール別にみんなでドンドン編集できるページや
コメント、タグが貼れるとさらに素晴らしいなと。
例えば
log で検索して log4j のページに行くと
いろんな人が使い方とか tips とか書いてて
コメントで
「commons-logging も入れときな」
「slf4j + logback の方が良いぜ！」
とか書いてある。
(EclipseWikiのプラグインページみたいな感じ？)
勿論タグも貼れてタグクラウドも表示！！
制作者がちゃんと伝えたい公式な部分は
mvn site-deploy
で出来る方に書くような感じで・・・
で、やっぱり検索部分なのですが、
みんなに見てもらった方が色々意見も出そうなので
貼っておきますね。
多分、矢野さんの言われているCPANのサーチ&ドキュメント
http://search.cpan.org/
個人的にスゲーと思っているgentoo-portage
http://gentoo-portage.com/
（ajax バリバリで感動しました）
以上、なんかいろんな所の良いところを
これでもかと詰め込む
妄想癖気味な文章でした。
(こういう妄想が語れて凄く嬉しかったりします。)
NIHONYANAGI,Yohji
非常に興味のある話題でしたのでお邪魔します。
個人的には Maven2 は非常に気に入っています。
依存関係のライブラリを漁る手間の解消や、
m2eclipse による pom.xml とクラスパスの同期化なんかは特に。
ただけっきょく、
ソースコードや Javadoc 、その他マニュアルなんかを見たい時はオフィシャルにアクセス…
という流れになってしまうんですよね。
> で、
> その集中管理しているところに行くと
> 依存関係もソースも Javadoc も全部見れるとか
こんな↑ことや、
さらに、
> 例えば
> log で検索して log4j のページに行くと
> いろんな人が使い方とか tips とか書いてて
> コメントで
> 「commons-logging も入れときな」
> 「slf4j + logback の方が良いぜ！」
> とか書いてある。
> (EclipseWikiのプラグインページみたいな感じ？)
> 勿論タグも貼れてタグクラウドも表示！！
こんな↑ことなんかがリポジトリ（もしくはリポジトリと連動するサイト）で
可能になるとほんとに嬉しい！
hoge-x.x-sources.jar とかhoge-x.x-javadoc.jar とかアップされているけど、
けっきょくこれって Eclipse みたいな IDE の為（だけ？）にあるような。
…まぁダウンロードできるだけまだ良いかな、とも思いますが。
しかもあったり、なかったり、という状態で。
あとはやっぱり「Maven Repo Search」みたいなインターフェイスがあるといいなぁと思います。
つい最近、JOTM を使ってみようと
xapool.jar を Maven2 のリポジトリで探してもなかなか見つからなくて、
けっきょく「Maven Repo Search」で調べたパッケージをヒントに見つけました。
※きっと「Maven2 Repo Search」的なものがそのうちリリースされるだろう、と我慢しつつ…。
> 個人的にスゲーと思っているgentoo-portage
> http://gentoo-portage.com/
> （ajax バリバリで感動しました）
はじめて知りました。
これからゆっくり「スゲー」と思いたいと思います。
--
━━━━━━━━━━━━……………‥‥‥‥・・・・
N I H O N Y A N A G I Y O H J I
二本柳 陽士
nihonyanagi.yohji＠gmail.com
・・・・‥‥‥‥……………━━━━━━━━━━━━
Tsutomu Yano
すみません、改行位置がめちゃくちゃになっていましたね。メールクラ
イアントの癖を忘れていた.... 以後気をつけます。
ヨシオリ
> すみません、改行位置がめちゃくちゃになっていましたね。メールクラ
> イアントの癖を忘れていた.... 以後気をつけます。
大丈夫です！！
肩を張らないコミュニティですから♪
一本釣りしたり一番失礼をしてるのが俺だったりしますし:p
というか、実はあんまり他の皆さんは
「 モジュールの集中ライブラリ」必要としてないんですかね？
どうですかね？
個人的には
櫻庭さん、ひがさん、あと個人的に
もっと絡んできて欲しい onk さんとかの意見も聞いてみたいなぁ♪
(と、懲りずにドンドン釣りまくる俺でした)
とのうち
非常に面白いと思います。とつられてみる。
プログラムしてると、あのモジュールどこだっけ？と迷うことが結構あります。
モジュール以上に迷うのが、そのモジュールのサンプル。サンプルが探しやすくなるのは、多
くのJavaプログラマに光明になりますね。
ふるーい話だと、SHAREのような感じも受けますね。両者のいいとこどり？という感じ？むむむ？
私が生まれるか生まれないかの時代の話なのであまり知りませんが＞SHARE
困ったときはあそこに行け、というのがあると、精神衛生上非常にいいですしね！
tarchan
Java版のCPAN、確かに欲しいなあと思います。
最近、Javaの雑誌が立て続けに休刊になってしまって、まとまった情報を得るのが難しくなってしまった感もあります。
立ち上げの際には自作のIRCライブラリも投稿したいと思います。
http://d.hatena.ne.jp/tarchan/searchdiary?word=%2a%5bLCHat%5d
またIRCにお邪魔します。
On 2月1日, 午前12:09, "Yoshiori Shoji" <yoshi...@gmail.com> wrote:
> どうも、ヨシオリです。
>
> ネタを投下したいと思います。
>
> 矢野さんの日記なのですが
> - モジュールの集中ライブラリが必要だ
> --http://d.hatena.ne.jp/t_yano/20060720/1153414595
> - 最新バージョンの自動検知はできるかな？
> --http://d.hatena.ne.jp/t_yano/20060731/1154363251