I work on apps that use various dependencies from various sources.
Some of them were sadly archived, so they won’t move to mavenCentral or anywhere else.
They will stay on jcenter forever.
Example is this one:
I’ve tried various ways to still use it, but without jcenter, and failed:
Took and used the AAR files from the cache (on C:\Users\User.gradle)
Import the project and see what I can do (got errors).
Use Jitpack (because it’s on Github), but it got errors shown right on the website itself
Building AAR file for each module and using them all (got a runtime crash).
Please provide a way to automate and safely use the dependency, by converting it to a completely local one (all files that the project will need).
Don’t just deprecate. Add a quick fix for Android Studio (and IntelliJ) of “convert remote dependency to local dependency”.
If you want to request a feature, you should do it on GitHub.
This is a community discussion and help forum.
But I doubt there will or should be anything more added by Gradle.
You can for example download those archived libs from JCenter or take them from the Gradle cache,
put them in a libs directory of your project and use a flatfile repository for them.
But actually the best move would probably be if you upload those libraries to Maven Central yourself, this way also other users of those libraries would benefit from that.
Just download the files from JCenter and then publish them on Maven Central as described at Choosing your Coordinates - The Central Repository Documentation.
I tried to use gradle cache (see point 1 in the first post of this thread), but maybe I did it wrong (copied just 2 AAR files that I think are related, as they have “twitter” in them). How can I know which files exactly to copy?
As for me uploading, I don’t know what to upload, and mavenCentral is quite a hard thing to deal with (I prefer Jitpack).
How can I download the files from JCenter manually?
Can be done even via the web browser?
I cannot tell you unfortunately, I didn’t touch Android development with a 4 foot pole yet, sorry.
I don’t know what might be missing.
Maybe other dependencies those dependencies have.
If you have JCenter in place and use dependencies task you should get a tree of the dependency hierarchy.
As documented, at the page I gave you, an “artifact bundle”.
You can for example build one by making sure the app is in your local maven repository (for example by building a dummy Maven project that uses the library) and then using the repository:bundle-pack goal of the Apache Maven Repository Plugin: Apache Maven Repository Plugin – Usage
This can build a bundle for you from the lib in the local Maven repository.
For more info on that you need to Google, that’s all I know, you can for sure also assemble the artifact bundle manually.
Not really. The initial getting set up with namespace claiming and getting signing done if you didn’t do it before and so on is a bit a PITA sometimes.
But after that it is easy peasy and the best you can do.
The lib will be persistent available, will not be changed once published and is available in almost all Gradle, Maven, and Ant/Ivy builds out there as Maven Central simply is the canonical Maven repository.
Well, the problem is, that JitPack is broken by design, unreliable, confusing, slow, bad in communicating problem, destroying Gradle Module Metadata while trying to rewrite it and absolutely unsuitable for proper publishing anything seriously, which also is not the intended and recommended use-case. It is only great for ad-hoc trying quickly out some things and only if it is not one of the cases where it destroys the built artifacts.
Yes, a Maven repository is just a HTTP file server with a conventional structure and some metadata files.
Never had a problem with Jitpack, not as a user and not as a “publisher” of libraries.
MavenCentral always has huge, long tutorials that make it very complex to understand. I failed quite soon to see how to use it.
But that’s not the topic for me.
How can I download the files from jcenter, that the app needs?
You lucky, lucky, guy.
Most people do not have that much luck.
To just name a few problems I personally stumbled over:
it is unreliable
it destroys the built files in a try to rewrite them to fit them into their strange conventions
if a version is requested the first time and the build needs too long, the build tool might remember that it couldn’t get the version there and even if then the build finished will not look again immediately
using SHA values as valid version totally destroys version ordering / proper conflict resolution
it builds strange catch-all artifacts for multi-project builds that totally work against proper api / implementation separation you might have put in place to make it less likely your users make an error
if there was a build error you don’t really notice and can only find it if desperate
the custom domain stuff does only half-way work
the support does not answer
the software does not do what the documentation states
it does not do what is configured (e. g. using oracle jdk when open jdk is set up)
if a build is not found at the root directory, they cd into a random directory and into different ones each time so sometimes a build works, sometimes not
…
I would always prefer the one-time ache of getting the MavenCentral account setup and the signing and so on put in place over using JitPack for actual publishing and use JitPack at best as a short-term ad-hoc playground for quickly trying something out dirty.