2021-02-04T09:43:39.000+09:00

JCenter / Bintray 終了による最悪のパターン妄想

下記のような記事を書いていて、

blog.s64.jp

恐怖を煽りすぎてもよくないから本体には書くべきでないと思ったけど こういうこともあるよね、みたいなパターンをいくつか思いついてしまった為ここに書いていく。

みんながみんなGitHub Packages等に移転したら？

BintrayやGitHub Packagesは、利用者ごとにリポジトリの名前空間を分けている。そのため別のユーザが作成したリポジトリからライブラリを参照する場合、それらは都度都度参照元のリポジトリとして書き足していくことになる。

もしあらゆるライブラリ作者がそうしたサービスに移転した場合どうなるか？当然参照先リポジトリ一覧はライブラリの数だけ記述が増える。
参照先リポジトリが増えることには弊害があって、

  1. URLが異なれば同じartifact idを持つライブラリを公開できる（場合が多い）。みんな好きにやったら衝突してしまうのでは？
  2. Gradle等の場合、依存関係は定義順に上から手繰っていく。増えれば増えるほど404でフォールスルーしていくのでHTTPのリクエスト数が増えていき、依存関係解決に掛かるコストがどんどん増えていくのでは？

という懸念を持っている。
2の話については下記の記事で書いている。

blog.s64.jp

古いバージョンは移転せず新しいバージョンだけ移転されたら？

今Bintray上でホストされているバイナリをすべて移転してさえくれれば、長期間メンテナンスされていないアプリでもリポジトリだけ書き換えればうまいこと動くだろう。
しかしもし古いバージョンは移転せず最近のバージョンのみ移転された場合は？そしてその間に破壊的変更があった場合には？

もしかしたら、リポジトリの移行だけでなく最新バージョンへの追従とそのための動作確認、のようなタスクが急遽入ってくるかもしれない。
ただ、これは珍しいケースになりそうだ。

ライブラリがメンテされていなかったら？

JCenterやBintrayでホストされているライブラリというのはビルド済のバイナリなので、当然ソースコードがメンテナンスされていなくても基本的にはダウンロードできる。
しかしもし随分昔に公開されたまま最近はメンテナンスされていなかったら？そのメンテナが移行作業を行わなかったら？

これはそのアプリの性質によってはかなりの割合で起きそうだ。年単位でメンテナンスされておらず移行作業もされそうにないライブラリはかなりある。もしそのようなライブラリを使用していた場合、最悪関連するコードを全部剥がして再実装することになるかもしれない。

最悪の場合を想定した対策

現行の依存関係すべてを解決し、jarファイル（aarファイル）をキャッシュしておいたほうがいいかもしれない。
まさにSonatype Nexusなどはこれに相当する機能を持っていて、Nexusがプロキシとなり各リポジトリから取得したアーティファクトをキャッシュできた記憶がある。

追記。そのほか興味深い指摘を頂いているのでここに列挙させていただく。