Reconsider adding support for jitpack.io repositories

[starsep]

In 2015 @championswimmer implemented a PR #551
It has been declined then due to low popularity of JitPack.io.

Some arguments for reconsideration:

• JitPack.io gained much popularity since then, it has > 2000 stars on GitHub, rise is also visible on Google Trends
• JFrog announced JCenter sunset: https://jfrog.com/blog/into-the-sunset-bintray-jcenter-gocenter-and-chartcenter/
• Gradle supports Kotlin DSL now, syntax for adding JitPack.io is different in Groovy

repositories {
    maven { url "https://jitpack.io" }
}

vs.

repositories {
    maven(url = "https://jitpack.io")
}

It would be consistent if jitpack() gets merged. Such an inconsistency is a PITA for library developers using JitPack.
If there is a will to merge such a change now I can create a PR.

Pinging @pioterj and @jitpack-io because they were involved in the discussion.
P.S. Sorry for creating a "duplicate" to aforementioned PR, I was afraid that response there would be ignored.

[melix]

There are different reasons why we're very reluctant on adding Jitpack.io as a first-level supported construct. In general, we even think it's not a good idea for any build to use Jitpack:

1. first of all, it's a security risk. On Jitpack, there's no control on who "owns" a group or artifact. It means that depending on the order of repositories you may introduce malicious code just by adding this repository in your build script. For this purpose, if you use Jitpack, you must absolutely use it in conjunction with repository content filtering
2. Jitpack break the concept of reproducible builds. You could argue that it's the same for SNAPSHOTs, but there are a couple things which make it worse for Jitpack:
   • a SNAPSHOT is normally controlled by the producer of a library, that is to say, the producer publishes a SNAPSHOT to a repository and you are allowed to consume it. With Jitpack a SNAPSHOT is controlled by the consumer, meaning that you cannot uniquely identify a "snapshot" (although I think jitpack caches by commit id)
   • a SNAPSHOT publication is done in a controlled environment (JDK, ...) where for Jitpack it's Jitpack which actually "decides" what goes in, what tasks to execute, ... which may lead to broken builds just because the wrong tasks were executed
3. Jitpack is intended as a "better replacement" for snapshots but in practice folks use it to avoid publishing on Maven Central. This means you don't get releases in the end.
4. another security argument is that the entity which builds the project (Jitpack) is not the entity who produces the project. How can you trust them in general (in the sense, how can you make sure that their infrastructure hasn't been hacked, that no malware is introduced in the resulting jar, ...)
5. a consequence of 4 is that it makes it much harder to use dependency verification and in particular impossible to verify signatures (which may be ok for development, but not for releases)

So we're not saying that there are not good use cases for Jitpack (there are, testing early releases without publishing is one), but that it doesn't make a good reason to make it too convenient to use given the risks.

[Vampire]

Another con is that it's unreliable and sometimes even appears broken as a build is done the first time a version is requested, if that build takes too long, Gradle remembers it is not there even if it then is until the cache period is over or you use --refresh-dependencies and if a build actually fails it is not too obvious to find the actual reason for that as a consumer, if the producer controls the builds it is his responsibility.

And one more, as partly the commit id is used as version, version ordering is not only useless but might prefer an older dependency in a conflict resolution just because it is lexicographically newer.

[melix]

To be fair to Jitpack, you could argue that there are stability issues with JCenter too but we still included it as first party. Same for Google which has a number of problems like not listing versions properly. This is really a tradeoff. The questions we need to answer are:

• is Jitpack popular enough that it's worth maintaining the DSL
• is Jitpack reliable enough that it won't make our test suite flaky
• if many folks are already using Jitpack, what patterns should we recommend, compared to say composite builds or snapshots for the consumer, and Maven Central for the producer

So not everything is against Jitpack, for some use cases it's pretty handy. But as a build tool we have a responsibility to make sure to promote good practices. At this stage I'm not clear about what the good practices for Jitpack would be. I'm sure there are some.

[Vampire]

Yes, JCenter has (had) reliability issues as well.
That's why I usually have MC too and as first if I need JCenter at all due to some dependency only being present there. (Or content filter now of course).

Another big con (currently) of JitPack is, that it destroys some aspects in the Gradle Module Metadata while trying to rewrite it for changed coordinates, but that is more a bug that hopefully gets fixed at some point.

From my personal point of view JitPack is nice for short experiments while I would usually prefer composite builds or source dependencies if possible, but should never be used for serious publishing of release artifacts.
But that's juts my 2ct.

Popularity-wise JitPack may indeed be a candidate for a built-in convenience method.
Maybe you should also think about a convenience method for https://oss.sonatype.org/content/repositories/snapshots/ where everyone that publishes to MC and publishes official snapshot builds publishes to. :-)

[Zhuinden]

Yes, JCenter has (had) reliability issues as well.

And JCenter also had actual security issues.

[DeJayDev]

Summoning Jitpack to get some of the main concerns put to the right eyes... @ajermakovics

In my world view, plenty of open source projects depend on Jitpack's building and serving of their dependencies, and for projects that might not have publishing (or in extreme cases, their platform is offline) Jitpack helps to provide that for them.

Jitpack's documentation even explicitly states that it's repo should be put last in your build.gradle:

Note: when using multiple repositories in build.gradle it is recommended to add JitPack at the end. Gradle will go through all repositories in order until it finds a dependency.

I want to further understand the stance against Jitpack, there are going to be issues with every platform at a really high level and to not "accept" Jitpack because of it's accessibility to the internet seems a little wrong to me.

[mlopatkin]

Closing because of reasons stated in #16310 (comment)