Handling JCenter's premature demise

Hi all,
you may have noticed that JCenter will go away - not as soon as it seemed initially, but still will go away. JFrog to Shut down JCenter and Bintray

By inspecting some of our builds, I’m noticing that there is a huge number of libraries and Java dependencies that are on JCenter only - Maven Central used to be (and I guess still is) a PITA to use.

In general, the more I think about it, the more I realize that a lot of what we do professionally depends on servers hosted by someone somewhere, without which our painfully written source code is kind of useless.

I plan to handle the situation by creating a local maven repo and uploading all third-party build artifacts there, so at least we won’t lose them, but… it is painful to do manually. Any better ideas?

The easiest way to populate your own Maven server with the stuff necessary to build your projects is to configure it up as a caching proxy for other Maven repos; point your mvn and lein settings at your Maven server only; and then build all your stuff. Once that’s done, you can check your Maven server and should see that it has downloaded and retained everything in its own coffers.

2 Likes

Jcenter looks like a bad idea, glad it’s going away. I also secretly wish Clojure moved back to Maven Central as it has proven most secure. Though at least Clojars doesn’t allow shadowing Maven Central.

1 Like

Personally I think that Clojars is usable, but Central… less so :slight_smile:
The problem is that it is very hard to tell what is where, and a missing dep has an unknown (and possibly huge) cost.

The only difference is central has a review process when creating your groupID and requires signing artifacts. It sounds inconvenient, but it only takes a few days and it’s why Central is more secure. It might seem a higher burden to publish, but I’d personally value higher quality libraries with better security and reliability of my dependencies.

I recognize the trade-off: convenience or security. Maybe because there’s been so much news about attacks from dependency hijacking and all I’m starting to lean on security.

Public Service Announcement

To put this kerfluffle in perspective, let us take note that Clojure Tools Alpha, which is slowly emerging from the muck, entertains dependencies specified as Git SHAs, which cuts out the middleman for pure-Clojure stuff. No Maven, no Clojars, no JFrog-repo-of-the-day, no shadowy and opaque middleman; just you and the remote Git repositories.

(P.S., The Git SHA is opaque, but, strictly speaking, no more opaque than semver. And, just think!, we could have avoided the whole hoopla to rev the pillars of the ecosystem to 1.0 a few months ago if folks had had only SHAs to look at.)

1 Like

Agree, Git shas are the best, they’re fully temper proof, as they are a full checksum of the source itself. I don’t mind them being opaque, especially since you can tag versions on commit, so it’s easy to find the sha for the version you want. Plus the git history is a full historical lineage of all versions (though including possibly non-release ready versions, which is where tags come in handy).

The problem here though is that almost all Clojure code base will rely on some Java dependency directly or transitively, so we will never be free of artifacts, unless those start being hosted on git as well (which might be a good idea as git support for binary data improves). Anyway this is dependent on the Java ecosystem. So for my Java artifacts I’d still prefer sonatype Maven Central as the repo, because they have a good record of reviewing what gets put in it.

Git shas are great for a project that is not a dependency, but libraries should stick to pinned versions. Otherwise users will get an error when one library refers to a dependency’s git sha and another refers to a pinned version. Since there’s no way for clj to know which to prefer, it throws.