Shinsuke SUGAYA
shins****@yahoo*****
2007年 1月 22日 (月) 22:18:49 JST
菅谷です。 --- Applied_MATSUDA Masaaki <m.mat****@appli*****> wrote: > > といいつつも，個別のwarファイルは，各ポートレットのリリー > スでそれぞれ配布されているわけですから，サイズのでかい > ポートレットパックを維持管理していくのは確かに馬鹿らしい > ですな・・・ そうなんですよね。結局、今後ポートレットが増えていくと、 ポートレットパック１，ポートレットパック２などと増えていく だけなので、維持していくのも大変ですし、PALポータルとして、 複数のものをバージョンのリリースとして置いておくと、混乱を 招くだけですし。ですので、PALポータルとしては、ポートレット パックを廃止して、バイナリとソースの２つだけをリリース物と して、置きたいと考えています。 ですので、ポートレットパックをやるとしたら、別のポートレット パックのサブプロジェクトみたいな感じにして、カテゴリ別みたいな ポートレットパックを作って、配布する感じが良いかと思います。 まぁ、これをどうインストールするかという話もありますが。 > RPADの仕組みや要件的に，想定外かも知れませんが，以下の > 提案が盛り込まれてはいかがだろうかと思います． 現在の状態では、RPAD は RPAD API と RPAD Portlet と 言う感じで分けられます。RPAD API はリモートでポートレット リポジトリにアクセスする API で、RPAD Portlet はリモートの リポジトリにあるポートレットを一覧して、配備を実行できる ポートレットです。現在のところ、RPAD Portlet にその要件は ないです。 > なので，いわゆるクライアント側のダウンローダになっちまう そういう気もするので、やるとしても、RPAD Portlet に含めず、 RPAD API を使った別物にした方が良いような気もします。 > かも知れませんけれど，企業等でポータルサーバとポートレット > パックをCDに焼いたものを導入するような場合は，ダウンロード > するときの担当者がポートレットパックを手配できるようにし， > ポータルサーバのインストーラが今までみたいにポートレット > パックを導入できるようになってるとばっちりそうです・・・ 確かに、そういう場合に焼くかもしれないですね。 RPAD API を使って、そういうポートレットを作るのもありかも しれませんね。 RPAD は、とりあえず、J2 に入れる予定ですが、そのうち、 Apache Portals の下に移すつもりでいます。ですので、 現状のところは、必要最小限の機能を実装するという感じで、 作っています。 > ていうか，いきなり話かわって， > なんか今おもいついたんだけど， > オンラインでポートレットを取れるようにするということは， > ・バージョン管理 バージョン管理もどうしようかと思っていました。 現状、ノーチェックです。 > ・アップグレードインストール 単に同じ名前なら、入れ替えになるかと思います。 > ・(ポートレット同士の依存性確認) 一応、依存関係の情報は設定ファイルにありますが、見ていません。 > 特に，PAL的にはDBもポートレットに内蔵ですから，アップグレ > ードでどっかんと，既存のポートレットDBがクリアされて > ガカーリとか・・・，あと以前の話題にもあった，テーブル構造 > がかわったときのいわゆるデータ移行をどうするか，なんてのも > 思い出してしまう具合です． そうなんですよね。現状、差し替えれば、消えていくので、 どうしたものかなっと思っていました。かといって、DB を 別に分けたくはないですし。やるとしたら、Import/Export 機能の強化(というか、実装してないので実装が必要)になる かと思います。何か、DB の内容を簡単に XML とかでうまいこと 吐いたり、飲み込んだりできるようなものはないですかね・・・。 shinsuke -------------------------------------- Start Yahoo! Auction now! Check out the cool campaign http://pr.mail.yahoo.co.jp/auction/
