simonpoole / OpeningHoursParser

Parser for string values according to the OSM opening hours specification
MIT License
32 stars 12 forks source link

Release artifacts need to move off of Bintray #56

Closed westnordost closed 3 years ago

westnordost commented 3 years ago

Bintray is shutting down, see https://jfrog.com/blog/into-the-sunset-bintray-jcenter-gocenter-and-chartcenter

Here is some useful information from gradle.org:

Impact to packages publishing to Bintray

If you are publishing your builds to Bintray using the com.jfrog.bintray plugin, you’ll need to find another repository to host your package. You may be able to publish using the built-in maven-publish.

If you’re migrating to Maven Central, the io.github.gradle-nexus.publish-plugin plugin automates publishing to Nexus and Maven Central.

Also important for anyone using JCenter to date to get dependencies is this security consideration:

As we have seen in recent years, dependency confusion and namespace collisions can be serious dangers for supply chain attacks. Each of these vulnerabilities relied on untrusted artifacts being used in place of trusted ones.

When you change the list of repositories you use to resolve dependencies, you may inadvertently expose yourself to these kinds of attacks.

Gradle offers a mechanism to defend against this, described in their user guide. In a nutshell:

Execute gradle --write-verification-metadata sha256 help to bootstrap checksum verification of dependencies, then after that you can change the repository to fetch dependencies from and gradle will throw an error if the checksum of a dependency now located somewhere else is different.

westnordost commented 3 years ago

I just moved the osmfeatures library to maven central, here is the gradle of that library, maybe you find this useful: https://github.com/westnordost/osmfeatures/blob/master/library/build.gradle

simonpoole commented 3 years ago

The problem is maven central is everything but low friction (which is why people were using bintray to start with), so currently I'm leaning towards using jitpack. f-droid is really the under lying problem here because all your dependencies need to be published in one of the small number of places they whitelist (in this case jcenter), not just what you are publishing for third party use.

westnordost commented 3 years ago

With low friction you mean that it is complicated to use and update? Yeah, bintray was more convenient. Though it has gotten better. The maven-publish gradle plugin is quite compact now. So my workflow now is to execute gradle publishMavenJavaPublicationToMavenCentralRepository, then go to https://oss.sonatype.org, login, click on Staging Repositories, select that repository, click on close, wait/refresh, click on release. I don't know if the whole interaction with that website can be avoided, but it was never so much pain in the ass that I actively tried to automate that step. But well, I guess https://github.com/gradle-nexus/publish-plugin doest just that.

Jitpack seems slick, but it is a little weird - who signs the published library? Jitpack itself?

simonpoole commented 3 years ago

Publishing moved in https://github.com/simonpoole/OpeningHoursParser/commit/a483b4dbd1205ea762bf6c40dbb9eb53ecf69d30

Heads up to @simon04