2021/02/09追記:
UPDATE: To better support the community in this migration, JFrog has extended the JCenter new package versions submission deadline through March 31st 2021.
To clarify, the JCenter repository will keep serving packages for 12 months until February 1st 2022. Only the JCenter REST API and UI will be sunsetted on May 1st 2021.
本日上記のとおりアップデートがあり、
と告知されました。本記事に記されている一部の日付が変わってくる為、ご留意ください。
JFrogが2021-02-04に発表した内容。Bintray, JCenter, GoCenter, ChartCenterが終了する。
詳細は1次ソースを参照してもらうほうがよいので、ここで細かい内容には触れない。
この記事は上記を既に閲覧していることを前提に、ではどのような影響を受けうるか、どのような対応が必要になるか、を現時点で想像可能な範囲で書いていく。
筆者はAndroidアプリ開発を主としている為、想像の利く範囲がJVMアプリケーションの知識以上になりづらいことをご容赦頂きたい。
何かしら救済措置やそれに相当するサービスが登場して、この記事に記す内容がハズレになってくれることを願う。
ところでurlで英語間違えててはずかしい
冒頭のサービスへの参照を直接記述しているプロジェクト（のビルド構成ファイル）のみ、と言いたいところだが、少し恐怖心を煽るならもっと広く「JVMアプリケーションを始めとしたMavenインフラを利用している全てのプロジェクト」としておいて、まずは確認することを促したい。
例えばJCenterに存在しMaven Centralに存在しないライブラリには、
など、広く使われつつも限定目的であるものならかなりある。
また前述の「Bintray上で独自にホストされたライブラリ」であれば、
などもある。
Gradleを利用して依存関係解決をしているアプリケーション（Android向けビルドのあるアプリなら確実にそうだろう）の場合、Gradleのビルド設定記述内に下記のようなブロックがあるはず。
repositories {
google()
mavenCentral()
jcenter()
maven {
url 'http://tokbox.bintray.com/maven'
}
}
この記述の場合、依存関係は Google Maven Repository -> Maven Central -> JCenter -> Bintray上の独自リポジトリ（この場合はOpenTok） という順で解決が試みられる。
ライブラリの中にはMaven CentralとJCenterの両方に存在するものもある為、そのような場合は影響を受けないだろう。
しかし上記のとおりJCenterにしか存在しないライブラリも存在するし、一番下にあるようなBintray上で独自にホストされたMavenリポジトリでしか配信されていないものもプロプライエタリなライブラリでは少なくない。
このようなライブラリの依存関係を持っている場合、
という作業を "該当する全てのライブラリに対して" 行う必要が出てくる可能性がある。
JCenterからの移転先としてMaven Centralが選ばれる可能性もあるので、実際の変更作業自体はそう多くないと予想している。が、少なくとも各ライブラリとそのメンテナがどんな動きを取るのか確認しておくべきだとは言えるだろう。
これは可能性としてだが、自分達の使っているライブラリがさらに他のライブラリに依存している場合、そういった遠い依存ライブラリのMavenリポジトリが変更されることも当然ある。
たとえばExoPlayerはAndroidにおいてデファクトスタンダードとなっているメディア再生ライブラリであり、これに依存したライブラリもいくらか存在する。もしこれが独自にホスティングされたMavenリポジトリや GitHub Packagesのような名前空間の分割されたMavenリポジトリに移転した場合、当然自分達もそれを追加する必要が出てくるはずだ。
多くのアプリケーションは事前に依存関係を全てパックした状態で配布される為、既に出荷済のバイナリであれば影響を受けないだろう。
一切メンテナンスを行わないのであればいいが、次にメンテナンスを行うのがJCenter終了後だった場合にはビルドができなくなっているはずだ。
事業としてライブラリを開発し配布することもしばしばあるが、当然こういった場合にもエンドユーザと同じような対応をまずは取らなければならない。使用している各ライブラリの動向をチェックすることだ。
そして自分達もまたそれを配布している場合、下記のような作業が入ってくるだろう:
自分達の製品が依存するJFrog系リポジトリ経由のライブラリが多いほど 顧客へ依頼する変更が多くなる可能性があることを考慮して進める必要があるが、どうしても依存先の方針決定を待つ必要もあるのが難しい。1回でまとめて連絡するのは難しくなるかもしれない。
一切メンテナンスを行っておらず、出荷済みのバイナリのみでビジネスを行っている顧客もまま居るだろう。このような顧客は強く影響を受けるわけではない。
ただし、当然自分達の更新や依存先の更新を反映してもらう為には改めて依存関係解決が実行してもらう必要が出てくるだろうし、その時には今回の対応を行ってもらう必要がある。
可能な限りは非アクティブな開発者にも対応を促しておいたほうがよいと考える。
どうにもならないパターンも発生しうるなと思った為、これは別記事に書いた。