New android projects doesn't include `maven { url ...

# android

[AmrJyniat]

New android projects doesn't include maven { url "<https://jitpack.io>" } by default, is there any documentation for this change?

[Vampire]

I'm not a Android dev, so no idea, but that is a good change. JitPack is slow, unreliable, and broken by design. I would never use it if it can be prevented and if not, then at most with a content filter.

[Matti MK]

@Vampire could you elaborate on that? Perhaps an article or something similar to familiarize

[Vampire]

Nope, just personal experience.
It has one use-case that is fine, if you want to "quickly" test against a specific commit or similar.
But for serious publishing it is just heavily broken due to serveral reasons.
Some of them (probably not complete):
• if a revision is requested first, the build has to be done, if that build is not very trivial it needs some time and the build tool will most probably time out, not getting the result, the build tool might also remember that it didn't work and not ask again for a certain amount of time even though the build could be finished in the meantime and the dependency available
• I've seen it down several times and for a significant amount of time
• conflict resolution like Gradle does with the "later version wins" is not possible reliably at all, as Git commit SHAs are also used as versions and they are not ordered "correctly" for that use-case
• unless you undergo a complex process you cannot use your normal coordinates, but coordinates derived from the GitHub username and repository name, so you can also not easily replace a normal publication with a JitPack build
• even if you done that complex process it sometimes doesn't work as expected
• due to the changed coordinates, their process also has to manipulate the generated metadata (POM, Gradle Module Metadata), but in certain situations they just destroy the POM, as their process is borked
• same as above but regarding Gradle Module Metadata, I don't fully remember, either they also destroy it in some situations or they don't adapt it at all which both is breaking behaviour
• if you have a multi-project multi-artifact build, the instructions on their website for your project are totally useless and cannot be adapted
• if you have a multi-project multi-artifact build, they generate an additional synthetic artifact which just depends on the single artifacts, but in a stupid way, especially if you already provide an own catch-all artifact that properly adds the api artifact to the compile scope and the implementation artifact to the runtime scope
• ... everything else I'm currently not remembering

[Vampire]

Imho it is always preferable to do proper releases to some repository, optimally Maven Central, even if the inital setup needs a bit of muscles.
Once it is setup, publishing is easy as pie and much better and more reliable.
And then is also available automatically in all Maven builds and in virtually all Gradle builds as any typical Gradle build out there has MC or JC (which delegates to MC if not having the artifact itself) as repository.