このページでは、GlassFish の開発に関する規則と規約について説明します。開発者はすべて、GlassFish にコードを送信する際、下記のプロセスに従う必要があります。管理方針については、こちらを参照してください。

目次

ワークスペースに関するガイドライン

ここでは、GlassFish ワークスペースに関連するプロセスを明確にします。ワークスペースで作業する場合は、これらのガイドラインを理解しておいてください。

モジュール相互の連携

• ほかに影響する可能性のある変更を行なった場合は、モジュール所有者リストを使用して連絡してください。 次に例を示します。
  • ほかのモジュールが依存しているインタフェースを変更した場合
  • コンポーネントを新しいメジャーバージョンにアップグレードした場合 (Ant 1.4.1 から 1.5、EJB API 2.0 から 2.1 など)
• プットバックの前に、ワークスペース全体がビルド可能であることを確認する必要があります。複数のモジュールが依存しているインタフェースを変更した場合、これは特に重要です。

保護されたモジュール

• glassfish モジュールと bootstrap モジュールは、特別な承認を受けずに変更してはいけません。これらを変更する必要がある場合は、dev@glassfish.dev.java.net に電子メールで連絡してください。簡略な説明と CVS 差分を提供してください。

バイナリ依存ファイル

• ワークスペースには、どのようなバイナリもチェックインしないでください。特に JAR ファイルは避けてください。同じ JAR ファイルの複数のバージョンがワークスペースに存在することを防止するためです。
• バイナリ依存ファイルを追加する必要がある場合は、dev@glassfish.dev.java.net に電子メールで連絡してください。バイナリの公式リリースまたはプロモートビルドの URL、およびバイナリの公式バージョン/ビルド番号も記載する必要があります。これらは、リリースエンジニアリングによって管理された周知の場所にコピーされ、複数のモジュールで使用できるようになります。

パッケージ化と DTD の変更

次のことを行う必要がある場合は、dev@glassfish.dev.java.net に電子メールで連絡してください。

• 最終製品イメージで公開するファイルの追加または変更
• サーバー設定 DTD に対する変更。変更によって、admin、CLI、および GUI の変更が必要になる場合があります。
• Application Server 固有の配備記述子 DTD に対する変更。変更によって、DOL、配備ツール、および Sun Java System Studio の変更が必要になる場合があります。
  

ログに関するガイドライン

GlassFish で使用されるログに関するガイドラインについては、次のプレゼンテーションを参照してください。

コーディング規約

GlassFish 用に開発されるコードはすべて、Java コーディング規約に従う必要があります。

コミット手順

夜間ビルドはすべて、毎日太平洋標準時の午前零時に始まります。この時刻前後には、ソースをチェックアウトしてすべてのプラットフォームでビルドを開始する時間が必要なので、コミットは 1 時間ほど保留してください。

一般的なチェックイン手順

1. 適切な技術者にコードをレビューしてもらいます。
2. 自分の分野外のコードを変更する場合は、モジュール所有者または技術リーダーと協議してください (モジュール所有者リストを参照)。
   
3. 1 つのモジュール内のファイルだけを変更した場合で、ファイルの削除を行なっていないときは、次のコマンドを実行します。
   • maven clobber
   • maven checkout bootstrap build
   • maven configure-runtime
4. ファイルの削除、ファイルの移動、または複数モジュールのコードの変更を行なった場合は、次のコマンドを実行します。
   • maven clobber
   • maven checkout bootstrap-all build
   • maven configure-runtime
5. 行なった変更の範囲と危険度に応じて、適切な回帰テストセットを実行します。チェックインの前に実行すべき適切なテストセットを判断してください。チェックインによっては、Quicklook では不十分な場合があります。必要に応じて、モジュール所有者や技術リーダーに相談してください。回帰テストは次のとおりです。
   • Quicklook テスト (すべてのチェックインに最低限必要)
   • 開発者ユニットテスト (強く推奨、一部のチームには必須)
6. コミットメッセージには次の情報を含めます。
   • 説明 (バグ修正の場合はバグ ID も)
   • コードレビュー担当者
   • 実行したテスト
7. 行なった変更がテストで十分にカバーされていることを確認します。開発者ユニットテストの実行を検討します。適切な SQE 技術者がこの変更について認識していますか。
8. これが新機能の場合、またはドキュメントに影響する場合は、ドキュメントチームに電子メールで連絡してください。

緩やかなコード凍結期間

• 目標は、リリースに向けて修正が予定されているすべてのバグ (P1 バグおよび P2 バグ) を修正することです。バグの危険性が高すぎて修正できない場合は、プロジェクトリーダーが延期することもできます。
• プロジェクトリーダーが明示的に承認するまで、新機能は許可されません。
  
• チェックインはすべて、同僚開発者またはモジュール所有者によるレビューと承認を受ける必要があります。
  
• ORB、JAX*、MQ などの統合はすべて、プロジェクトリーダーの承認を受ける必要があります。dev@glassfish.dev.java.net に電子メールで連絡してください。

厳しいコード凍結期間

• この期間は、緊急事態への対応だけに使用されます。既知のバグはすべて、緩やかなコード凍結期間で修正済みのはずです。
• バグをリリースに含めるための検討依頼は、dev@glassfish.dev.java.net に電子メールで送信してください。その際、件名に「ShowStopper」と記載してください。
  
• 緩やかなコード凍結期間と同じ手順に従いますが、致命的なバグだけに対処します。
• チェックインはすべて、プロジェクトリーダーによるコードレビューと承認を受ける必要があります。
• プロジェクトリーダーは、毎日、承認されたバグ修正と次のリリースまで延期されたバグのリストで回答します。

コードレビュー担当者用チェックリスト

1. あなたは適切なレビュー担当者ですか。
2. コードを 1 営業日以内でレビューできますか。できない場合は、誰かに委任できますか。
3. バグ修正の場合は、提出済みのバグがありますか。
4. 変更がテストで十分にカバーされていますか。
5. 変更について理解できるように十分なコメントがコードに含まれていますか。
6. コードは I18N に準拠していますか。
7. エラーに関するログメッセージはありますか。メッセージ ID は付いていますか。メッセージのレベルは適切ですか。わかりやすいメッセージですか。ログメッセージはパフォーマンスに重大な影響を与えますか。
8. コードの書式は、ファイル内のほかのコードと同じですか。Java コーディング規約に従っていますか。
9. 設計は論理的に正しいでしょうか。モジュールのほかの部分の設計と調和していますか。堅牢性は十分ですか。
10. 同様の修正が必要かどうか調査する必要のある関連分野がほかにもありますか。
    

コード提出者用チェックリスト

1. バグ修正の場合は、提出済みのバグがありますか。
2. コードはレビュー済みですか。
3. 適切な回帰テストをすべて実行しましたか。
4. 変更に関する情報をドキュメントライターとテスト担当者に送信しましたか。
5. 変更がテストで十分にカバーされていますか。新しいユニットテストを作成すべきでしょうか。
6. ワークスペースを最近更新してありますか。適切なブランチを使用していますか。CVS の衝突をすべて確認し、解決しましたか。
7. 変更について理解できるように十分なコメントがコードに含まれていますか。
8. コードは I18N に準拠していますか。
9. エラーに関するログメッセージはありますか。メッセージ ID は付いていますか。メッセージのレベルは適切ですか。わかりやすいメッセージですか。このログメッセージはパフォーマンスに重大な影響を与えますか。
10. コードの書式は、ファイル内のほかのコードと同じですか。Java コーディング規約に従っていますか。

事後レビュー/チェックイン用チェックリスト

1. 要求された変更をすべて組み込み、レビューを受けましたか。
2. 新しいファイルをすべてリポジトリに追加しましたか。
3. 更新と再コンパイルを行い、適切なテストを実行しましたか。
4. すべての変更を一緒にチェックインし、チェックインコメントに説明、レビュー担当者、および実行したテストを記載しましたか。複数の分野に渡る変更の場合は、変更されたファイルのリストもログメッセージに含めることをお勧めします。
5. 変更がバグ修正の場合は、Bugtraq で課題を integrated に更新し、バグをカバーするユニットテストまたは Quicklook テストを示すポインタも指定します。
6. ユーザー機能に影響する変更、またはユーザー機能を妨げていたバグに関連する変更の場合は、テストグループやドキュメントグループなどのすべてのグループに変更を通知します。

Quicklook テスト

Quicklook テストは、Application Server の多くの機能を広くカバーするテストです。開発者が Application Server の主要機能のテスト、および主要機能が壊れていないことを確認するための妥当性検査を実行できるように用意されています。

Quicklook テストを実行するには、次の手順に従います。

1. GlassFish をインストールするか、maven bootstrap を使ってビルドされたサーバーイメージ (${glassfish.home}) を入手します。ビルド手順を参照してください。
   
2. Quicklook テストのチェックアウト: 上記の手順で glassfish/bootstrap モジュールをチェックアウトしたら、「checkout-quicklook」maven ゴールを使って Quicklook テストをチェックアウトします。この maven ゴールでは、appserv-tests モジュール全体をチェックアウトするのではなく、Quicklook テストの実行に必要な数ファイルだけをチェックアウトできます。

cd workspace (サーバーコードを格納しているディレクトリ)
cd glassfish/bootstrap
maven checkout-quicklook

cvs -d :pserver:<userid>@cvs.dev.java.net:/cvs checkout glassfish/appserv-tests

setenv PATH $S1AS_HOME/bin;$JAVA_HOME/bin;$MAVEN_HOME/bin;$PATH

set PATH=%S1AS_HOME%/bin;%JAVA_HOME%/bin;%MAVEN_HOME%/bin;%PATH%

% cd $APS_HOME
% maven runtest

% cd $APS_HOME
% maven runtest-ee-standalone

% cd $APS_HOME
% maven runtest-ee

メモ:

• 任意の build.xml ファイルに対するデフォルトターゲットは usage です。% ant を実行すると、単独で実行可能なモジュールのリストが表示されます。
• 上記で指定した runtest ターゲットは、GlassFish Server インスタンスを起動し、Derby を起動し、概要レポートを作成します。

モジュール所有者

ドキュメントのコメントの記述方法

Javadoc コメントの記述方法については、次のドキュメントを参照してください。

パッチの提出

適切に記述された適用しやすいパッチは、ほかの開発者に歓迎され、モジュールやコンポーネントをより安定した強力なものへ向上させることに役立ちます。パッチを提出する最初の手順は、Contributor Agreement に署名して返送することです。このフォームを印刷し、必要な詳細をすべて記入してから、こちらに返送してください。

• まだ GlassFish のメンバーになっていない場合でも、メーリングリストにアクセスできれば、提案するパッチに関するメッセージをプロジェクトの開発者メーリングリストに投稿できます。プロジェクトのメーリングリストへの登録については、こちらを参照してください。
• GlassFish メンバーであれば、まず GlassFish 課題データベースを照会して、すでに報告されている欠陥にこのパッチが関連しているかどうかを調べます。
• 「Sun Java System Application Server/J2EE SDK」カテゴリの Web バグも確認してください。
  

既存の課題に関連するパッチであれば、課題編集画面の「新規添付の作成」リンクを使ってパッチを提出し、「追加コメント」セクションで説明メッセージを投稿するようにしてください。課題に変更を加えると、その課題の所有者および cc リストに登録されている全員に対して、電子メールメッセージが自動的に生成されます。あなたのメッセージとパッチへのリンクが、全員に送信されます。

課題が存在していない場合は、「課題の追跡」ページの「課題の入力」セクションの「パッチ」リンクを使って、新しい課題としてパッチを提出します。最新のソースを使用するようにワークスペースを更新し、GlassFish サーバーを再度ビルドする必要があります。また、何も壊れていないことを確認するために、Quicklook テストを実行することを強くお勧めします。その後、次の手順に従って、この新しい課題にパッチファイルを添付します。

1. まず、必ず最新のソースファイルに対して変更を加えるようにします。そのためには、CVS を使って CVS トランクのソースをチェックアウトし、変更を加えてから (ただし、チェックインは行わず)、次のコマンドを実行することをお勧めします。

   cvs diff -c > mypatch

   このコマンドによって、ソースに対するコンテキスト形式のパッチが生成されます。これによって生成されるパッチファイルには、パッチの適用対象であるバージョン、ファイル名、および変更の内容に関する情報が含まれています。この推奨手順を使用すると、パッチの追跡が可能になり、ほかのユーザーがパッチを見つけてテストしやすくなります。

2. パッチを適用するには、適切なディレクトリに移動し、次のコマンドを実行します。

   patch < issuepatch.diff

3. パッチには常に、次の情報を記載したメッセージを含めてください。

   • 修正しようとしている問題または欠陥に関する説明、および、可能な場合は、その再現手順。
   • パッチの適用によって得られるはずの動作に関する説明。
   • 適切な場合は、パッチの動作に関する説明。大量のコードが関連している場合は、適用されるプロジェクトライセンスの下でパッチが IDE コードの一部として使用されることに同意する旨を、メッセージ内に記載してください。
   • java ソース、スクリプト、およびドキュメントも含むテストケース。このテストを appserv-test/devtests テストスイートに追加する場合に利用します。
     

影響を受けるコード部分に責任を負う開発者は、パッチを適用し、欠陥が登録されている場合は欠陥を修正済みとしてマークするようにしてください。あるいは、パッチが安全でないか問題の解決にならないと考えられる場合や、実際に対処すべき問題が存在しないと思われる場合は、異議を回答するようにしてください。課題データベースに対する変更や CVS チェックインを行なうと、適切な課題担当者および CVS メーリングリストの cc 登録者に自動的に通知が送信されるので、パッチが適用されたかどうかを監視できます。少なくとも、作業しているプロジェクトの CVS メーリングリストと課題メーリングリストには必ず登録してください。

問題の修正方法が正確にわからない場合でも、その原因に心当たりがあれば、これに関するメッセージを開発者ディスカッションリストに投稿して、ほかのプロジェクトメンバーの意見を求めたり、修正方法のわかる人を探したりすることができます。