仕様策定委員会 on Jakarta® EE: クラウドネイティブJavaの新ホーム

Jakarta EE TCK Process 1.3

webdev@eclipse-foundation.org (Eclipse Foundation) — Mon, 07 Feb 2022 00:00:00 +0000

Eclipse Foundation仕様プロセスにおける仕様プロジェクトは、
複数の互換実装を可能にするという目的を実現するためにTechnology Compatibility Kit（TCK）を
作成する必要があります。

このドキュメントでは、次の事項を定義します。

移植性の実現のために適切と考えられる、TCKが提供しなければならない資料
最終TCKの承認
テストに対する異議申し立てプロセスとその解決方法
リリース済みのTCKテストを認証要件から除外する方法
リリース済み仕様に対するTCKテストの改善方針
自己認証手続
TCK異議申し立てを解決するための（TCKの）サービスリリース（x.y.z）のプロセス

役割と制限

TCKの役割は、
実装の互換性とアプリケーションの移植性の両方を確保することです。

TCKテストは、
仕様の規定、商標ガイドライン、ライセンス条項を含むがこれに限定されない、
アプリケーションが遵守すべきすべてのルールおよび制限事項に従って記述される必要があります。アプリケーションに関するこれらの規則および制限に従わない
テストは無効とみなされ、
異議申し立てプロセスで除外される場合があります。

名前空間

TCKテストは jakarta.* 名前空間にパッケージ化しないでください。
現時点では、TCKは他の名前空間にパッケージされていても構いませんが、
名前空間の形式は ee.jakarta.tck.<spec-name> が推奨されます。

TCKリリースの資料

アーティファクト:

プロジェクトは、Maven Centralまたは他のオープンソース
チャンネルに配布するためのプロジェクトライセンス（EPL、Apacheなど）
バージョンを作成し、自動化された非公式テストと
実装に使用可能である必要があります。このTCKをもとに
互換性を主張することはできません。
プロジェクトは、
EFTLライセンスを含む最終候補バイナリを作成する必要があります。Jakarta
EE仕様策定委員会は、最終承認後、Eclipseインフラを通じて配布するために、プロジェクトTCKバイナリ
を署名してプロモートします。これ
は、互換性を主張したい
場合に自己認証に使えるTCKバイナリで、Jakarta
ブランドの使用を許可するものです。
両方のTCKバイナリには、以下が含まれる必要があります
- ユーザーガイドのアウトライン
  - ソフトウェア要件
  - インストールと構成
  - テストの実行方法
  - 異議申し立てする場所
  - このプロセスガイドでカバーされていないTCK固有の規則
- TCKの検証に使用される互換実装の
  実行方法を記載した説明書
- 上述の
  各ドキュメントを指し示すトップレベルのREADMEドキュメント
TCKのドキュメントには次の項目を含めることを推奨します
- 認証申請、バグ
  レポート等のイシュートラッカーのURL
- 互換性を主張する前に、互換性認証
  プロセスに
  従わなければならないことを示す文。
TCKバイナリは、以下を含むことができます。
- テストカバレッジ文書
- テストアサーション文書
プロジェクトのGitHubリリースページ(または
同等ページ)から利用可能なリリース
- EFTL下の最終リリースは、次の場所でホストされる必要があります:
  download.eclipse.org

最終TCKの承認

プロジェクトは、EFTL版TCKの最終バイナリ案を仕様策定委員会の
承認のために提出します。

Jakarta EE互換実装と互換製品

webdev@eclipse-foundation.org (Eclipse Foundation) — Thu, 11 Mar 2021 00:00:00 +0000

Jakarta EEは、エンタープライズJavaアプリケーション開発に使用されるオープンな仕様のセットです。これは、Java EE技術の後継で、将来のクラウドネイティブJavaエンタープライズアプリケーションの仕様を前進させることに興味を持つJava開発者が集まった幅広いコミュニティです。各仕様リリースには、関連するTechnology Compatibility Kit（TCK）が含まれます。TCKへのリンクは、該当する仕様リリースページにあります。例えば、Jakarta EE Platform 9.0、または、コンポーネント仕様の場合は、Jakarta Authentication 2.0を参照してください。

Jakarta EEワーキンググループでは、コンポーネント仕様のすべての互換実装に焦点を当てることができます。さらに、Jakarta EEワーキンググループは、Jakarta EEプラットフォームまたはJakarta EE Webプロファイル仕様の互換実装である互換製品に焦点を当てています。

実装をJakarta EE互換として指定する際の最初のステップは、対応する仕様との互換性を実証するために、各TCKに対応する適切な仕様をパスし、Eclipse Foundation Technology Compatibility Kit Licenseの利用規約に準拠していることを確認することです。これは、実装者が、TCKのマニュアルに記載されている要件、特にTCKユーザーガイドに記載されている要件を含め、各仕様のすべての互換性要件を確認していることを前提としています。

TCKが成功裏に通過したら、次のステップは、それを世界に知らせることです。つまり、次の項目を実施します。

GitHubのイシューを提出して仕様プロジェクトチームに通知し、承認を得て、
PRを作成して、Jakarta EEワーキンググループが適切な仕様ページに互換実装をリストできるよう支援します。互換製品の場合は、Jakarta EEプラットフォーム仕様および/またはJakarta EE Webプロファイル仕様の実装が互換製品ページに掲載されます。

Jakarta EEワーキンググループへのメンバーシップを含む、追加の必要な手順があります。互換製品ページに掲載されている製品は、Jakarta EE商標ガイドラインに従い、Jakarta EE互換ロゴを使用することができます。

Jakarta EEコンポーネント仕様の互換実装としてリストされる方法

個々のJakarta EEコンポーネントの仕様ページで、あなたの実装を互換実装ページとして表示するには、次の手順に従います。

Jakarta EE TCKプロセスに従って、該当するTCKテストのすべての要件を完全に満たして実行し、Eclipse Foundation TCKライセンスに準拠します
- 仕様の互換性を主張し続ける限り、TCKの結果を公開し、TCKの結果の公開リストを維持してください。
- TCKの結果をtck@eclipse.orgにメールで送信します。
GitHubリポジトリの仕様プロジェクトに認証リクエストイシューを提出します
Jakarta EE仕様リポジトリに対してGitHubプルリクエスト（PR）を開き、必要な情報を入力します

Jakarta EEプラットフォームまたはJakarta EE Webプロファイルの互換製品として掲載される方法

あなたの製品を互換製品ページに表示し、Jakarta EE互換ロゴを使用できるようにするには、次の手順に従います。

ブランドと互換ロゴの要件
- Jakarta EEワーキンググループに参加します
- Jakarta EE商標ガイドラインを参照します。
- Jakarta EE Compatibility Trademark License Agreementを実行（デジタル署名）します（またはLicense Agreement PDFを印刷し、署名した契約書をemo-records@eclipse.orgに返送します）
互換認証とjakarta.eeの互換製品ページ掲載の要件
- Jakarta EE TCKプロセスに従って、該当するTCKテストのすべての要件を完全に満たし、実行します
  - 互換性を主張し続ける限り、TCKの結果を公開し、TCKの結果の公開リストを維持します。
  - TCKの結果をtck@eclipse.orgにメールで送信します。
- GitHubリポジトリに仕様プロジェクトを含む認証リクエストを提出します。
- GitHubイシューを開き、Jakarta EE互換製品リポジトリに対して必要な情報を入力します

Jakarta EE仕様プロセスガイド

webdev@eclipse-foundation.org (Eclipse Foundation) — Thu, 04 Mar 2021 00:00:00 +0000

Content

はじめに

このガイドは、Jakarta EE仕様プロセスの開発者がJakarta EE仕様プロセス（JESP）のステップをナビゲートするのに役立つステップバイステップの実用的なガイドです。

便利ツールとして提供するものですので、疑問がある場合は、必ずJESPを参照してください。 Jakarta EE仕様の開発に関するご質問・ご意見等ございましたら、仕様委員会まで、お気軽にお問い合わせください。JESPは、Eclipse仕様プロセス（EFSP）を採用しています。

This diagram is the Eclipse Specification Version Lifecycle. It shows the steps to create and evolve a Specification.

The most important kind of step in the lifecycle is the Review step. A Review is an event that takes place over a week or two of calendar time. The team developing a Specification creates some kind of artifact and submits it to the Specification Committee for review. The Specifiation Committee has a short amount of time to review the submitted artifact and conduct a ballot among its members to approve or not-approve that artifact under review. This guide contains a sufficient explanation of Review, but if you want the full definition, see the Eclipse Foundation Specification Process and the Eclipse Foundation Development Process.

Jakarta EE仕様策定委員会の運営

webdev@eclipse-foundation.org (Eclipse Foundation) — Wed, 13 Jan 2021 00:00:00 +0000

このドキュメントでは、Jakarta EE仕様策定
委員会の実務について説明します。

このドキュメントへの変更は、Jakarta
EE仕様策定委員会（jakarta.ee-spec@eclipse.org）のメーリングリストを通じて行われるJakarta EE仕様策定委員会の
単純な多数決により承認される必要があります。

これは公開文書です。

仕様策定委員会

Jakarta EE仕様策定委員会は、Jakarta EEワーキンググループの管轄下で、
すべての仕様プロジェクト（この用語はEFSPによって定義）の
Eclipse Foundation Specification Process（EFSP）を
実装する責任を負います。これには、
Jakarta EE Specification Process（JESP）と呼ばれる、Jakarta用
EFSPの適応が含まれます。

仕様策定委員会は、ワーキンググループの仕様プロジェクトによって作成された
最終仕様の妥当性の確認に対して最終的な
責任を負います。「妥当である」という定義は、仕様策定委員会の参加者によって異なりますが、
一般的には、仕様が実装可能であり、
本質的クレームに関するEclipseの知的財産ポリシーの
側面が遵守されていることを意味すると
理解されています。実際には、仕様策定委員会の参加者は、EFSPに従って、
主要なライフサイクルイベントを承認するために必要な投票を通じて
権限を行使します。

仕様策定委員会は、仕様プロジェクトの運用ガイダンスドキュメントを
作成、発行、維持する責任を
負います。これには、最終仕様を
作成するための最小要件とプロセスが含まれます。また、互換性をテストする目的で
仕様TCKを実行する操作ガイダンスも
含まれます。

仕様策定委員会の委員長（またはその代理）は、
投票の開始、結果の集計、コミュニティへの伝達、
また（適切な場合、例えば、Releaseレビューの投票の場合）結果を
EMOに報告します。

仕様策定委員会は、また、その管轄下にある仕様プロジェクトに対して、
EFSP/JESPを実施する方法を定義し、改善する
責任を負います。

プロジェクト管理委員会（PMC）

PMCの主な役割は、プロジェクトチームが
Eclipse開発プロセスを実装していることを確認することです。特にPMCは、
プロジェクト活動を監視して、プロジェクトチームが
オープンで透明な方法で確実に作業を行えるようにします。PMCがコミッターの選挙をレビューおよび承認（または否認）します。
まず、コミッター候補者が
十分な利点を示していることを検証します。

PMCは、さらに、プロジェクトチームが
Eclipse IPポリシーを遵守し、IPデューデリジェンスのプロセスを実施する責任を負います。
実際には、PMCは知的財産貢献（CQs）を承認し、
知的財産に関する（限定的な）ガイダンスをプロジェクトチームに提供します
（必要に応じてEclipse IPチームに委ねます）。

PMCは、トップレベルプロジェクトの構造と、
それに含まれるオープンソース（ソフトウェアと仕様）プロジェクト
の組織化に責任を負います。

PMCは、プロジェクトリーダーシップチェーンの一環です。そのため、PMCは
苦情処理プロセスでの役割を担います。
プロジェクトの機能不全を特定して文書化します（破壊的なコミッターを
削除/更迭/追加する責任があります）。

PMCは、オープンソースプロジェクトの運営に関するその他の
監督も行います。ReleaseレビューおよびProgressレビューに関する資料をレビューし、承認します。
また、トップレベルプロジェクト内のプロジェクト間のコミュニケーションを促進します。

プロジェクトリードの指名

仕様プロジェクトでは、プロジェクトリードとして
1人以上のコミッターを指名する必要があります。リードは、プロジェクトが適切なマイルストーンに到達したときに、
レビューを開始する責任があります。