• javadoc を全てのメソッドに使う。
• インターフェースを定義し、このインターフェースの実装を提供する場合、 インターフェースのメソッドにJavadocを差し示す為の@seeタグを使ってください。 その後、実装が重複しないようにする為、全てのJavadocにインターフェースが定義されている状態を保ってください。
• 戻り値（@returns）、メソッドパラメタ（@param）、例外（@throws）を全て記述してください。
• 新規のメソッドを定義する場合、そのパッケージが何をするかを規定するpackage.htmlファイルを含めるようにして下さい。
• メソッド或いはクラスに変更を加える場合、@authorタグに自身の名前を入れて下さい。また、電子メールアドレスもお願いします。

メソッドとパラメタの間にスペースを使ってください：

	この代わりに： this.test(true,true,"test",true); 以下のようにして下さい： this.test( true, true, "test", true );

括弧を使ってください。開発者の中には、どのようにソースコード内に括弧を置くかについての個人的な好みがある人もいます：

	if ( true ) { //body } あるいは if ( true ) { //body }

新規ファイルに関しては、貴方のお好きなスタイルをお選びください。 しかし、修正しようとするソースの既存スタイルは保持するよう努めてください。

メソッドに複数パラメタがある場合、複数行にまたがるよう分けて下さい。

	長いパラメタのリストを１行に置く代わりに、パラメタ・リストに複数行にわたる改行を入れてください： private final PortletSet getPortlets( Portlets portlets, RunData rundata, boolean application, boolean applicationsOnly ) { } private final PortletSet getPortlets( Portlets portlets, RunData rundata, boolean application, boolean applicationsOnly ) { }

テストは、バグの検知とバグの防止の為の非常に優れたやり方です。 テスト処理を自動化することで、テストが簡単に動き、失敗が見極められるようになります。 Jetspeed では、Ant に組み込まれるテスト機能、主にCactusやJUnitを使います。

指針

テストクラスの名前はTestで始まるようにし、 testパッケージ内に入るようにします。 全ての新しい機能には適切なテストを入れるべきです。JUnitテスト、Cactusテスト、あるいは其の両方のどれでも構いません。 バグフィックスには、適切なテストの追加物や何がフィックスされたかを特定する（つまり、問題を検知し問題をフィックスするテストを修正する）ための変更履歴も入れておくべきです。更新されたテストは問題が解決した事を保証すべきです。 CVS checkoutの後、cvs updateの後、cvs commitの前に、必須テストを動かしてください。 適切なテストを早めにかつ頻繁に行って下さい。

テスト・スィート

必須テスト 必須テストは、コード（バグが無い事を望む）動作保証に使われるCactusとJUnitテストから構成されています。 テスト実行用コマンド 説明 build unittest-all 全ての必須ユニットテストを実行します build tests_tomcat_32 全てのTomcat 3.x (JSP 1.1) のテストを実行します build tests_tomcat_40 全てのTomcat 4.x (JSP 1.1) のテストを実行します ユニットテスト・グループ 論理的にグループ化されたユニットテストがあります。 テスト用階層構造をもつ場合があります。unittest-securityの場合は、 セキュリティ実装のテスト、すなわちunittest-security-registryとunittest-security-turbine で構成されています。 以下、利用可能なユニットテスト･グループの単なる例です。 テスト実行用コマンド 説明 build unittest 一般的ユニットテスト。長時間に亘るテストはここには含まれません。 build unittest-security Jetspeed Security 実装の一般的ユニットテスト build tests_cache キャッシュ・サブシステムの一般的ユニットテスト

Cactus

Cactusテストは、動作時にデータが必要な場合に使われます。 そのテストは通常、「beginTestName()」メソッドによるURL生成が伴います。 このURLは、「testTestName()」というテストメソッドに渡され、 Cactusによって開始されるウェブサーバーで動きます。 Cactusテストの実行は、サーブレットエンジンのバージョンに依存します。 現在、Cactusテストを追加する箇所がbuild.xmlに２つほどあります。 org.apache.jetspeed.test.BasicSecurityTestとorg.apache.jetspeed.template.TestJetspeedLink に、Cactusテストのサンプルがあります。 Cactus のドキュメントは、 http://jakarta.apache.org/cactusにあります

JUnit

JUnit は、ウェブサーバーを必要としない事もあり、Cactusテストをよりシンプルにしたものです。 これらのテストは、一般的に、（データ構造にファイルを読み込むといった）小さい機能的ユニットをテストします。 Turbine サービスも JUnit テストでテストされます。org.apache.jetspeed.services.registry.TestMarshallRegistryをご覧下さい。 org.apache.jetspeed.services.registry.TestMarshallRegistryと org.apache.jetspeed.template.TestJetspeedLinkFactory に、JUnitテストのサンプルがあります。 JUnit のドキュメントは、 http://junit.orgにあります

一般的に、ログ取得は最小限にとどめておくべきです。ログ取得は、問題の診断と解決に非常に有効です。 エラーメッセージがエラーを表示し、そこには実践的な「原因」と「解決策の提案」があります。

デバッグ・ログ取得は、開発と問題測定に使ってもらう為のものです。通常の製品環境で使う為のものではありません。 ある意味、必要とするリソース（CPUやディスク容量を含む）のせいで、です。ですから、デバッグメッセージを生成する前に デバッグ・ログ取得が可能かどうかを測定するのにLog.getLogger().isDebugEnabled()メソッドを使ってください。

	if (Log.getLogger().isDebugEnabled()) { Log.debug("JetspeedRunDataService: accessing rundata " + m_runDataStore.get(Thread.currentThread()) + " for thread: " + Thread.currentThread()); }

• ファイル構成。現在のディレクトリ構成に従って全てを整理し続けて下さい。 例えば、ドキュメントを./src/javaディレクトリ下に置かないようにして下さい。
• 基本的なjava.lang.Exceptionを投げないようにして下さい。 Jetspeed の内で内部的問題として投げられる全ての例外は、 org.apache.jetspeed.util.JetspeedException（PortletException.javaをご覧下さい）を拡張すべきです。