以下の 18 個です。
level | KPA | ||
---|---|---|---|
5 | DP | Defect Prevention | 欠陥予防 |
TCM | Technology Change Management | 技術変更管理 | |
PCM | Process Change Management | プロセス変更管理 | |
4 | QPM | Quantitative Process Management | 定量的プロセス管理 |
SQM | Software Quality Management | ソフトウェア品質管理 | |
3 | PR | Peer Review | ピアレビュー |
SPE | Software Product Engineering | ソフトウェアプロダクトエンジニアリング | |
ISM | Integrated Software Management | ソフトウェア統合管理 | |
IC | Intergroup Coordination | グループ間調整 | |
TP | Training Program | トレーニングプログラム | |
OPD | Organization Process Definision | 組識プロセス定義 | |
OPF | Organization Process Focus | 組識プロセスフォーカス | |
2 | SCM | Software Configuration Management | ソフトウェア構成管理 |
SQA | Software Quality Assurance | ソフトウェア品質保証 | |
SSM | Software Subcontract Management | ソフトウェア外注管理 | |
SPTO | Software Project Tracking & Oversight | ソフトウェアプロジェクト進捗管理 | |
SPP | Software Project Planning | ソフトウェアプロジェクト計画 | |
RM | Requirements Management | 要件管理 |
http://www.fujixerox.co.jp/randd/12/17_haman/tr102.html を参考にさせていただきました。
Capability Maturity Model の略です。日本語では「能力成熟度モデル」と訳されることが多いようです。
CMM は成熟度を 5 段階で定義し、各成熟度の段階には Key Process Area として改善すべき項目を挙げています。
まず、外部ホストの CVS に対して ssh 経由でアクセスできるように設定しておきます。
$ export CVSROOT=:ext:user@hostname:/path/to/repository $ export CVS_RSH=ssh
この上で ssh が socks 経由で外部ホストにつなぐことができるようにします。
以下のサイトより connect.c をダウンロードし、コンパイルします。
コンパイル方法もこのページに示されています。
http://www.imasy.or.jp/~gotoh/ssh/connect.html
次に ~/.ssh/config に利用する socks サーバーなどの設定をします。
設定についてもこのページに示されています。
この状態ですでに ssh が socks 経由で外部ホストに接続できるはずです。
接続できるのであれば cvs も同様に問題なく利用できます。
外部ホストに接続できないのであれば設定に問題があるかもしれません。記述を見直すべきです。
もし、あなたが Windows ユーザーでかつ商用で cvs を利用しているのでなければ SocksCap が利用できます。
この場合、 cvs クライアントを SocksCap に登録してそこから起動するだけです。
WinCVS なども利用できるでしょう。
リモート先のリポジトリは以下のようなリポジトリ名でアクセスします。
:method:user@hostname:/path/to/repository
pserver が立っている場合、 method は pserver ですが、そうでない場合には ext か server を試してみるとよいでしょう。
この場合、 cvs が rsh 経由で指定のホストに接続してやりとりしてくれます。
もし、ホスト側で rsh が利用できない場合には method を ext にし、かつ環境変数 CVS_RSH に ssh を指定するとよいでしょう。
この場合、 rsh 経由で接続していた部分が ssh 経由になります。
最近の unix 系ホストでは一般的に sshd が立っていることが多いのでうまくいくでしょう。
最近はやりの O/R mapper です。
http://www.hibernate.org/
日本では Apache Torque の方がメジャーですが US などでは Hibernate の方が人気があるようです。
Hibernate の方がドキュメントも充実しています。
できます。
実装できるかどうかと言う点では CGI を利用できる言語ならできるでしょう。
Java servlet では HTTP method PROPFIND や HTTP method PROPPATCH をサポートしていないので javax.servlet.http.HttpServlet#service() を自分で拡張する必要があるでしょう。
WebDAV クライアントで一覧したい場合には HTTP method PROPFIND を実装すればそれなりに動作するでしょう。
ファイルやディレクトリの作成が必要なら HTTP method PUT や HTTP method MKCOL の実装が必要です。
どんな方法にしろ Apache + mod_dav と Windows や MacOS のやりとりをキャプチャして動作を確認するのがよいでしょう。
Digital Rights Management の略で、デジタル著作権管理のことです。
web などインターネット経由でコンテンツをやりとりする場合に著作権に対するライセンス管理をする仕組みです。
Google で検索してみてください。
http://www.google.co.jp/search?hl=ja&ie=UTF-8&oe=UTF-8&q=Digital+Rights+Management&lr=
もしホスト名が複数あり、それぞれに対するリクエストを適切に処理させたいのであれば virtual host として解決するのがよいでしょう。この場合、実行しているインスタンスは 1 つです。
具体的には $CATALINA_BASE/conf/server.xml 内に複数の Host element を記述することで指定します。
... <Engine name="Catalina" defaultHost="localhost" debug="0"> <Host name="localhost" debug="0"appBase="webapps"
unpackWARs="true" autoDeploy="true">
...
</Host>
<Host name="localhost2" debug="0"appBase="webapps2"
unpackWARs="true" autoDeploy="true">
...
</Host>
</Engine>...
また、httpd として apache から呼ばれている場合はさらに jk のドキュメントが参考になるでしょう。
http://jakarta.apache.org/tomcat/tomcat-4.1-doc/jk2/jk2/vhosthowto.html
もし何らかの理由で異なる JavaVM で動作させたい場合には $CATALINA_BASE を分けるのがよいでしょう。
Tomcat を 1 つだけ動作させている場合、通常 $CATALINA_BASE は $CATALINA_HOME と同一のディレクトリです。
複数のインスタンスを実行させる場合にはインスタンスごとにディレクトリを決めます。このディレクトリが $CATALINA_BASE になります。さらにここに必要なディレクトリを作成します。具体的には以下のような構成にします。
$CATALINA_BASE /conf /logs /shared /webapps /work
$CATALINA_BASE/conf の下に server.xml をはじめとして設定ファイルをいれます。
$CATALINA_BASE/logs にログが出力されます。
$CATALINA_BASE/shared に web application 間で共有したいライブラリやクラスファイルを入れます。
$CATALINA_BASE/webapps に web application を入れます。
$CATALINA_BASE/work が Tomcat の作業ディレクトリになります。
なお、 $CATALINA_BASE/conf/server.xml の記述によっては一部これ以外の構成も可能です。この場合は単一インスタンス時の設定と変わりません。
呼べます。ただし HTTP/1.1 の web サーバーに対してです。
具体的には Range ヘッダをつけることで実現します。
RFC2068 が参考になります。
mozilla のレンダリングエンジンを利用した軽量ブラウザです。
もともと Firebird という名前で公開されていましたが version が 0.8 から Firefox という名前になりました。
理由は以下の通りです。
http://www.mozilla.org/projects/firefox/firefox-name-faq.html
Firebird はもともと interbase を元にした Opensource の RDBMS の名前でしたので、これを回避するために改名したようです。
ちなみに Firebird という名前も Phoenix という名前から改名したものでした。
もしあなたが java エンタープライズアプリケーションの構築に関わっている、もしくは関わろうとしているのであればおそらく IBM の Application Server である WebSphere Application Server の略のことでしょう。
WAS に関しては IBM のサイトに情報があります。
http://www-6.ibm.com/jp/software/websphere/
web.xml のスキーマに servlet 2.4 用のスキーマを指定していないのではないでしょうか?
もしそうであれば web-app element を以下のように指定します。
<web-app xmlns="http://java.sun.com/xml/ns/j2ee"xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee web-app_2_4.xsd"
version="2.4">
このとき 2.3 以前のスキーマをしている部分の削除を忘れないように。
また、 Tomcat の work ディレクトリ以下も削除して JSP を再コンパイルさせるとよいでしょう。