This is a really short timeline and a huge pain. I maintain 3 popular (thousands of github stars) Android libraries hosted on JCenter and published via Bintray. These libraries are stable and I update them only a few times a year.
Now I have 4 months to re-do the publishing pipeline for them and figure out how to republish older version artifacts on MavenCentral and educate my users.
I think few who haven't tried it realize what a massive pain it is to publish a library on Android. Compared to Cocoapods or NPM, Android library ecosystem is a joke. Every library I know of has their own hacked-together build script. This is why most Android apps use only libraries from Google and Square, the two dominant library publishers.
There was never much love between JFrog and the Android community so this puts an end to that saga, but it's not clear who will step up. Bintray / JCenter was never great but it did attempt to make publishing easier and it was the default.
Seems like JFrog is under massive pressure by GitHub, GitLab and the big cloud providers. The big companies are starting to move to those services and all the small ones are already there. No one needs an on-prem artifact repo for this setup.
There are also rumors that JFrog will change the licensing of their products in the next months.
The notice is really short for such a takedown - cornered animals sometime make bald moves.
This is very big and will affect a lot of java projects, JCenter is one of the most important central repositories currently available, specially because of bintray since publishing to actual maven central was quite a lot harder than bintray.
This actually makes the world a better place. Every serious Java project is capable of meeting Maven Central‘s few requirements and publish artifacts there. Bintray is just a place to put stuff on the internet. Which serious project would use artifacts from such a place?
Publishing to maven central isn't particularly difficult, but it is a high friction process.
You have to file an issue on a JIRA board.
Provide proof of owning a namespace(dns txt record, or github).
Wait for a human to review and approve the ticket.
Create a PGP key.
Publish the PGP key to public key servers.
Submit your builds via the webapp.
Wait for the verification process to complete.
Have it fail a bunch of times randomly, because despite uploading your PGP key to as many of the keyservers as you could, there seems to be a huge key replication delay between keyserver instances, and the verification process can't find the key published.
Once verified, actually publish the build.
Most of the pain is one off, once you have gone though it, publishing new builds can be automated.
The PGP signing is pointless, you can sign with any key you like, and change the key as often as you like, just so long as the key is published.
10 years in the industry, I have never heard of anyone checking the signatures on maven artifacts.
> The PGP signing is pointless, you can sign with any key you like, and change the key as often as you like, just so long as the key is published. 10 years in the industry, I have never heard of anyone checking the signatures on maven artifacts.
Seconded - the process is fine if you're an Apache project or whatever, but for an individual developer with a handful of small libraries to share, it's not worth it.
The process is also not difficult for individual developers. Most of the steps to publish on Maven Central have to be done only once and there is good documentation about how to do it. Meeting some minimum requirements, such as proving namespace ownership or defining a license, improves the quality of a public artifact repository significantly. Who wants to use artifacts from a repository where everyone can just dump their stuff whithout any checks? Or who wants to use software that is based on such dependencies? Although Maven Central is not a perfect place either, you can at least be sure that the artifacts there meet some basic requirements.
> Which serious project would use artifacts from such a place?
Plenty of them, since it's just adding a few lines to either pom.xml or the Gradle script. Sure, maybe there's rules against it in your org, but if it works then a code reviewer might say whatever, there's bigger problems
That's probably the end for them, who would trust a company that kills products that are so central to the whole software building ecosystem, with such a short notice? We are moving everything we had in there and will certainly not be looking back.
I concur, this can easily be seen as burning bridges with the dev community (which is of course a terrible idea when your product primarily interfaces with developers).
This is a major PITA and is derailing a lot of other plans. I'm pretty astonished that they are stopping submissions by Feb 28th. Pretty amazing JCenter is going away too.
Seems bad news for the Homebrew community as well. Isn't it plausible that some old, less popular but perfectly working formulae will stop working, at least for a while?
I particularly hope that the migration won't mean that older binaries (e.g. Python 2) will disappear completely. Even if homebrew deliberately won't serve them today, they are a valuable archive.
There are other offerings for a package distribution use case - https://cloudsmith.com being the most clear alternative. Support for 23+ package types, comprehensive API and CLI, package signing support, global PoP's etc.
Full Disclosure - I work at Cloudsmith, and I genuinely think it's awesome. If anyone has any questions feel free to reach out to me - dan at cloudsmith dot com
1. What is the workflow for a single tired developer who just wants to publish a few Java packages from Gradle? Is there a howto or tutorial for this?
2. Your "supported formats" list [1] is just icons, which is very cute, but i have absolutely no idea what the icons for Gradle or Maven are, so i was sat there mousing over every one to see what you have. I highly recommend captions on those icons.
2a. The Go link on that page is broken.
2b. The "pop culture banner coming soon" stamps made me laugh, good work.
3. Have you approached Gradle about getting added as a convenient / default repository? Adding cloudsmith() rather than a full repo string would be a tiny but perhaps significant bit smaller speedbump to adoption.
There are how-to's / guides in a few places. For gradle, you have our general documentation like https://help.cloudsmith.io/docs/gradle-repository and then within your repositories you have contextual "set me up" docs, which come ready to cut and paste into your configs. A little hard to explain without showing you, which I'm happy to do at any stage if you want a call to chat.
Our free trials are fully featured, and our free plan includes public repositories of course also.
https://www.dist.cloud/ offers private Maven and Docker repositories and may be a good fit for Bintray users privately sharing and distributing artifacts/images. Our primary goals are simplicity, reliability, and performance.
However (recognising that this is what a lot of folks use Bintray for), we don't offer any free plan, nor public repositories. This is a deliberate decision as we are bootstrapped and our end-goal is a sustainable business focused on private distribution.
Full disclosure: I am a founder of Dist, happy to take any feedback and questions.
> we will continue to offer both free and paid JFrog Platform cloud subscriptions that can serve other binary distribution needs
Can you use this JFrog Platform thing to publish Maven artifacts? If so, is the story really "everyone needs to migrate from JCenter to JFrog Platform"?
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.
Now I have 4 months to re-do the publishing pipeline for them and figure out how to republish older version artifacts on MavenCentral and educate my users.
I think few who haven't tried it realize what a massive pain it is to publish a library on Android. Compared to Cocoapods or NPM, Android library ecosystem is a joke. Every library I know of has their own hacked-together build script. This is why most Android apps use only libraries from Google and Square, the two dominant library publishers.
There was never much love between JFrog and the Android community so this puts an end to that saga, but it's not clear who will step up. Bintray / JCenter was never great but it did attempt to make publishing easier and it was the default.