Service end for Bintray, JCenter, GoCenter, and ChartCenter
jfrog.com
jfrog.com
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.
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.
The "no writes after 28 Feb" is a new twist...
Removing jcenter as a source in the buildscript is a trivial step but doesn't remedy the issue as the dependencies are not all mirrored elsewhere.
Complexities of setting up a Maven central account is often listed as the main cause for maintainers simply going for JCenter instead.
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
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.
I check them on every build, with the pgpverify maven plugin: https://github.com/m50d/tierney/blob/master/free/keys.proper... . Presumably I'm not the only one since that plugin exists.
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.
Is there a complete mirror available already?
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.
Again, thanks for the feedback. Super Helpful.
1. We have fixed the link for Go
2. We have added some rollover captions for the formats, and you can also see a full list here : https://help.cloudsmith.io/docs/supported-formats
3. we haven't yet approached Gradle, but it's absolutely something we will look at.
Thanks again. Very much taken on board.
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.
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"?
Hopefully they can find an alternative to publish latest binaries as it takes time for upstream Ubuntu to move to new rabbitmq and erlang release.
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.