Pretty sad to see them go but understandable as hosting this can't be cheap. That being said, 3 months notice is a bit of a shit show and indicates either their bankruptcy is imminent or their management are a bit clueless and simply don't care about the impact of their choices to their own business.

Hint: any chance of me doing business with them just went out of the window. Their reputation just went down the toilet and they probably don't realize that yet. I can't emphasize how bad that must look to their paying customers. But as I'm not one of those, I'm grateful for them having hosted this so far of course.

Of course a lot of jcenter dependencies are propagated to maven central. So, it doesn't necessarily mean your dependencies will be gone. Most mature projects on jcenter would have set that up. Of course it still affects a lot of early access and development stuff that would have gone through them but not be propagated to jcenter.

In any case, this would be a good opportunity for the likes of Github, Amazon, Google, etc. to step up and offer a public OSS repository and make their own arrangements with the Apache Foundation to get their dependencies propagated to maven central. Most of these companies probably already have a good working relation ship with the Apache Foundation.

Meanwhile, some alternatives:

- deploy to maven central. This is a bit of a PITA to set up currently as it requires manual approval via the Sonatype's issue tracker. A large reason for Jcenter's popularity was the process with Sonatype being a PITA and JCenter making it a lot easier to deploy stuff quickly. I imagine Sonatype will be mildly overwhelmed by the traffic in the next months. I've gone through the process a couple of times and they are fairly nice about it but it just takes some time and there's a bit of complexity involved with creating/managing keys, etc.

- use jitpack.io, it's easy. They deploy straight from Github hashes and tags. I've used this on a few projects. Sadly, they have some issues with kotlin multiplatform libraries; there's an open issue for that. But if your build is set up right, this can be very convenient as all you have to do is tag a release. Important to note, this even works with repositories that never signed up for this: you can pretty much get it to build anything on github. So, in a few months when countless builds start breaking because of JFrog walking away from this, that might be a quick fix.

- deploy to a file or web server. I do this for one of my libraries. Easy to setup, low tech, and it does not require any special software. Basically a maven repository is designed for CDNs and static hosting. The repository software is basically just about managing/creating files and part of a deploy is actually creating those files locally and then uploading them. You can host a maven repository on just about anything and there are maven plugins and out of the box support in gradle for s3, gcs, https, scp, and probably a few more protocols. I use this routinely for internal stuff and a few of my kotlin multiplatform modules (support for that is flaky in many mave repos). I bet there probably is somebody that figured out how to host on IPFS even. I currently have a few public libraries on my website that I deploy using rsync as well as a few things that I put on gcs buckets for internal use.