http://openjdk.java.net/jeps/296 をテキトーに訳した。
JEP 296: Consolidate the JDK Forest into a Single Repository
Author Joseph D. Darcy Owner Joe Darcy Created 2016/10/07 18:42 Updated 2016/10/26 23:34 Type Infrastructure Status Candidate Component infrastructure/build Scope Implementation Discussion jdk9 dash dev at openjdk dot java dot net Effort M Duration S Priority 3 Reviewed by Brian Goetz, Mikael Vidstedt Release 10 Issue 8167368
Summary
多数のJDKリポジトリ群を単一リポジトリに統合して開発の簡易化と効率化を行います。
Non-Goals
JDKへのFXのソース追加は本JEPには含めません。
Motivation
長年の間に、JDKの完全なコードベースは多数のMercurialリポジトリに分割されてきました。JDK 9では8個のリポジトリroot, corba, hotspot, jaxp, jaxws, jdk, langtools, and nashornがあります。
複数リポジトリには何点かの利点がある一方で様々な欠点があり、あるべきソースコード管理オプションサポートが貧弱になっています。とりわけ、内部的に依存関係のあるチェンジセットの複数リポジトリにまたがるアトミックなコミットが出来ません。たとえば、いま単一のバグフィックスあるいはRFEのコードがjdkとhotspotリポジトリの両方を触るとした場合、両リポジトリへの変更を個々のリポジトリに対してアトミックに実行出来ません。複数リポジトリ変更はよくあることで、1,100以上のバグidがリポジトリで再利用されています。この1,100個という数字は論理的なリポジトリ横断バグ数の下限に過ぎず、その理由はエンジニアによっては異なるリポジトリへのプッシュに異なるバグidを使用しているためです。
上述のMercurialリポジトリの分断とエンジニアの作業単位のミスマッチにより近代的なソースコード管理管理の主なメリットである、個々のファイルではなくファイルのチェンジセットのトラッキング、が薄められています。その結果、SCMトランザクションと論理的なトランザクションとのミスマッチはMercurial bisectなどのツール使用を困難にしています。
JDK全体とは別の開発サイクルを個々のリポジトリが持つわけではありません。すべてのリポジトリはJDKのプロモーションサイクルに歩調を合わせます。多数のリポジトリは新規の開発者に対する障壁となり、"get source"スクリプトなどの回避策を取らせることになりました。
Description
これらの問題解決のため、統合リポジトリのプロトタイプが作られました。プロトタイプは以下で利用可能です。
http://hg.openjdk.java.net/jdk9/consol-proto/
プロトタイプ作成に使われた変換スクリプトのいくつかはunify.zipでアタッチされています。
このプロトタイプでは、個々のファイルレベルのヒストリーを保持する自動変換スクリプトで8個のリポジトリを単一リポジトリに統合しており、JDKプロモーションをマークするのに使われるタグで統合コード群を同期化しています。チェンジセットのコメントと生成日も維持しています。
プロトタイプでは異なるコード整理のためのレベルを導入しています。統合リポジトリでは、Javaモジュールのコードは基本的には単一トップレベルsrcディレクトリ下に結合しています。たとえば、現在のJDKリポジトリには以下のようなモジュールベースのディレクトリがあります。
$ROOT/jdk/src/java.base ... $ROOT/langtools/src/java.compiler ...
統合リポジトリでは以下のように編成されます。
$ROOT/src/java.base $ROOT/src/java.compiler ...
結果として、リポジトリルートからのモジュール内のソースファイルの相対パスは統合後はsrcディレクトリ下に維持されます。
テストディレクトリに対してはやや異なる再編成策を計画しています（ただし実装は未完成）。*1
$ROOT/jdk/test/Foo.java $ROOT/langtools/test/Bar.java
上記から以下にします。
$ROOT/test/jdk/Foo.java $ROOT/tests/langtools/Bar.java
まだプロトタイプであるため、不完全な部分がありますが改善は可能です。$ROOT/jdk, $ROOT/langtoolsなどのディレクトリに残存ファイルがまだありますが、それらのファイルは以降の作業で再編成を予定しています。HotSpot C/C++のソースはモジュール化したJavaコードと共に共有srcディレクトリに移動します。
jtreg設定ファイルのアップデートサポートは現在作業中です（JDK-8165187）。
Alternatives
代案の一つとしては単に現行のリポジトリセットのままにしておくことが挙げられます。単一リポジトリ以降時にはリポジトリのヒストリーの全てあるいはいくつかが消失する可能性がありましたが、that was rejected*2。リポジトリの中核セブセットを統合することも考えられましたが、単一リポジトリの明快さという点で無しになりました。
Testing
ファイルの中身の検証には、あるタグの旧リポジトリの内容とそれに対応する同じタグの統合リポジトリの内容を検証するスクリプトを使用しています。最新のJDK 9のタグでは、同一タグの統合リポジトリと旧リポジトリのビルドが比較されており、少数の説明がつく差異のみが存在します。
Risks and Assumptions
上述のテストによりファイル衝突とビルド失敗の重大なリスクを軽減すべきです。統合に必要な作業の大部分はプロトタイプ上に完成していますが、JDK 10でオープンにしたいと考えているその時までに各種の小規模サポート機能は準備出来ないかもしれません。統合前後のコードベースはMercurial senseでは関連がありません。チェンジセットのエクスポートとインポートとは対照的に、foward-portとback-portのためにはDiffs (with suitably massaged paths)を使う使う必要がああります。*3
