JCenter / Bintray等が停止することで起きる影響を考える

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.

本日上記のとおりアップデートがあり、

  • 新しいバージョンの公開は約1ヶ月延長され、3月末日まで可能に
  • 5月1日に廃止されるのはAPIやUIのみ、ホスティングは2022年2月1日(約1年間)までと明記

と告知されました。本記事に記されている一部の日付が変わってくる為、ご留意ください。


JFrogが2021-02-04に発表した内容。Bintray, JCenter, GoCenter, ChartCenterが終了する。

jfrog.com

詳細は1次ソースを参照してもらうほうがよいので、ここで細かい内容には触れない。
この記事は上記を既に閲覧していることを前提に、ではどのような影響を受けうるか、どのような対応が必要になるか、を現時点で想像可能な範囲で書いていく。
筆者はAndroidアプリ開発を主としている為、想像の利く範囲がJVMアプリケーションの知識以上になりづらいことをご容赦頂きたい。

何かしら救済措置やそれに相当するサービスが登場して、この記事に記す内容がハズレになってくれることを願う。

ところでurlで英語間違えててはずかしい

影響をうけるエンドユーザとその対応

冒頭のサービスへの参照を直接記述しているプロジェクト(のビルド構成ファイル)のみ、と言いたいところだが、少し恐怖心を煽るならもっと広く「JVMアプリケーションを始めとしたMavenインフラを利用している全てのプロジェクト」としておいて、まずは確認することを促したい。

例えばJCenterに存在しMaven Centralに存在しないライブラリには、

  • いくつかの広告SDK
    • MoPub Android SDK
    • Tapjoy Android SDK
    • AppLovin Android SDK
    • ほかいろいろ
  • JetBrainsの提供するごく一部のライブラリ
  • Groupieなど個人で開発されている多くのOSS

など、広く使われつつも限定目的であるものならかなりある。
また前述の「Bintray上で独自にホストされたライブラリ」であれば、

  • ExoPlayer (bintray.com/google/exoplayer)
  • OpenTok (bintray.com/tokbox/maven)

などもある。

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リポジトリでしか配信されていないものもプロプライエタリなライブラリでは少なくない。

このようなライブラリの依存関係を持っている場合、

  • まずはそのライブラリの配布サイト(GitHubリポジトリなど)を確認する
  • 配布するMavenリポジトリをどこに変更するかアナウンスを見つける
  • ビルドスクリプトをそれに従い変更する

という作業を "該当する全てのライブラリに対して" 行う必要が出てくる可能性がある。

JCenterからの移転先としてMaven Centralが選ばれる可能性もあるので、実際の変更作業自体はそう多くないと予想している。が、少なくとも各ライブラリとそのメンテナがどんな動きを取るのか確認しておくべきだとは言えるだろう。

間接的な影響

これは可能性としてだが、自分達の使っているライブラリがさらに他のライブラリに依存している場合、そういった遠い依存ライブラリのMavenリポジトリが変更されることも当然ある。

たとえばExoPlayerはAndroidにおいてデファクトスタンダードとなっているメディア再生ライブラリであり、これに依存したライブラリもいくらか存在する。もしこれが独自にホスティングされたMavenリポジトリや GitHub Packagesのような名前空間の分割されたMavenリポジトリに移転した場合、当然自分達もそれを追加する必要が出てくるはずだ。

余談: 出荷済バイナリは影響を受けるか

多くのアプリケーションは事前に依存関係を全てパックした状態で配布される為、既に出荷済のバイナリであれば影響を受けないだろう。
一切メンテナンスを行わないのであればいいが、次にメンテナンスを行うのがJCenter終了後だった場合にはビルドができなくなっているはずだ。

ライブラリ配布者の影響

事業としてライブラリを開発し配布することもしばしばあるが、当然こういった場合にもエンドユーザと同じような対応をまずは取らなければならない。使用している各ライブラリの動向をチェックすることだ。

そして自分達もまたそれを配布している場合、下記のような作業が入ってくるだろう:

  • 自分たちがJCenterやBintrayを利用している場合、できるだけ早く移転作業を行う
    • 今回は5月1日がデッドラインであり、これ以降ライブラリが取得不能になる為
    • また2月28日には新しいバージョンを受け付けなくなる為、アップデート配信の都合上決定は急ぐ必要がある
  • 顧客向けに、リポジトリの列挙内容として不要になるもの、新たに追加してもらう必要があるものをできるだけ迅速に伝える
    • 間接的に依存するライブラリがあった場合、それ用の新たなリポジトリを追加しないと依存関係が正常に解決できない場合がある
    • 連絡が遅れた場合、顧客側スケジュールにおける動作確認予定等の都合で 必要なアップデートが提供できない可能性がある

自分達の製品が依存するJFrog系リポジトリ経由のライブラリが多いほど 顧客へ依頼する変更が多くなる可能性があることを考慮して進める必要があるが、どうしても依存先の方針決定を待つ必要もあるのが難しい。1回でまとめて連絡するのは難しくなるかもしれない。

塩漬けされた顧客プロジェクトの場合

一切メンテナンスを行っておらず、出荷済みのバイナリのみでビジネスを行っている顧客もまま居るだろう。このような顧客は強く影響を受けるわけではない。

ただし、当然自分達の更新や依存先の更新を反映してもらう為には改めて依存関係解決が実行してもらう必要が出てくるだろうし、その時には今回の対応を行ってもらう必要がある。
可能な限りは非アクティブな開発者にも対応を促しておいたほうがよいと考える。

追記: 最悪のパターン

どうにもならないパターンも発生しうるなと思った為、これは別記事に書いた。

h.s64.jp