zjupure/GlideWebpDecoder

Migrate Artifacts to Another Repository

commonsguy opened this issue · 27 comments

This library is being published to JCenter. JCenter is being taken down on May 1 2021.

Ideally, this library would migrate to publish its artifacts on Maven Central or some other artifact repository.

Thanks for considering this!

Many libraries of Google are still in jCenter. I think we should wait until their library migrations.

Is there any workaround for this?
The date is coming soon and plenty of libraries are at risk, not being able to use them as a dependency...
Is it possible perhaps to use this using a different way? Jitpack? aar/jar ?

@commonsguy Do you know perhaps of a similar library that offers the same but is available without jcenter ? I need to be able to handle both animated GIF and WEBP, and be able to get their frames as they are being played.

BTW, for some reason your link causes my web browser to download a file "download"...

@AndroidDeveloperLB

The date is coming soon

JFrog changed their plans a bit. JCenter is not accepting new submissions in May, but they will continue to serve artifacts for the rest of the year. My hope is that they stick to that plan. If so, we have more time.

Do you know perhaps of a similar library that offers the same but is available without jcenter ?

I have not looked for one. My project's needs are just to play animated WebP (no need to access frames).

@commonsguy Do you know of a workaround? Is it possible to use Jitpack to import what's here? Or to use aar/jar ?
Surely when we add a dependency, some files are downloaded to gradle cache, or something, right?

As for alternatives, I think Fresco might be able to do it, but it's a huge library that for some reason I failed to use.

@AndroidDeveloperLB

Is it possible to use Jitpack to import what's here?

Sorry, I have never tried setting anything up with Jitpack, so I have no idea.

Surely when we add a dependency, some files are downloaded to gradle cache, or something, right?

A copy of the library will be in your Gradle cache (~/.gradle on macOS and Linux). You would have to look at the POM to see what dependencies it uses.

Or, simply fork this repo and build it yourself. Or, fork this repo and integrate it as a module in your project. Or, see if somebody else forks the repo and opts to maintain this. Or, wait to see if the repo maintainer switches artifact repositories.

@commonsguy OK thank you very much. I've noticed many forks from here. Wonder if one of them migrated.

It's a very trivial matter for individual libraries to move their repository from jCenter to mavenCentral. As long as the Google libraries are in jCenter, we have no choice but to use jCenter and there is no workaround.

@dalinaum But Google already allows to use mavenCentral instead. Download the beta/canary versions of Android Studio, change from jcenter to mavenCentral, update gradle plugin to :

classpath "com.android.tools.build:gradle:4.2.0-beta05"

Or to:

classpath "com.android.tools.build:gradle:7.0.0-alpha08"

And it will allow you to build fine.

As @AndroidDeveloperLB had asked on reddit how to solve this, here's a how-to workaround for others :)

  1. Go to https://bintray.com/zjupure/maven-home/com.zlc.glide%3Awebpdecoder/2.0.4.12.0#files/com%2Fzlc%2Fglide%2Fwebpdecoder%2F2.0.4.12.0 and download the .aar file (you can also download the others for sources/documentation but it's not strictly necessary)
  2. Follow https://stackoverflow.com/a/32087456/3991578 on Android Studio 4.2 (seems like it got changed in the Arctic Fox Canary version, can't import jar/aar there anymore, likely a bug)
  3. Add api project(':$PROJECTNAME') to your app/build.gradle, replacing the old one.
  4. Done!

@carstenhag Would it suffice for this case:

    def GLIDE_VERSION = '4.12.0'
    implementation "com.zlc.glide:webpdecoder:2.0.${GLIDE_VERSION}"
    implementation "com.github.bumptech.glide:glide:${GLIDE_VERSION}"
    kapt "com.github.bumptech.glide:compiler:${GLIDE_VERSION}"

Meaning that instead all those 4 lines, I would use a single one?

No. As long as this issue (#76) isn't closed and you can't get com.zlc.glide:webpdecoder from a remote repo, you will need to include it manually if you want to remove jCenter today.

Therefore it doesn't make sense to use the version variable, as you need to download a new verson manually anyway.

So you will end up with something like this:

    def GLIDE_VERSION = '4.12.0'
    implementation "com.github.bumptech.glide:glide:${GLIDE_VERSION}"
    kapt "com.github.bumptech.glide:compiler:${GLIDE_VERSION}"

    api project(':glide-webpdecoder-2.0.4.12.0.jar') // This references the local imported module/jar.

@carstenhag So this is the end result, while also not having jcenter?

The previous solution is a workaround, because this project is currently only provided on jCenter.

Once it is also available elsewhere, you can remove this workaround. Hope that cleared it up :)

@carstenhag I mean that using this workaround, the end result will be as you wrote, while also not having jcenter?

Yes.

@carstenhag I can't find the "import jar/aab" option:

image

Android Studio 4.2 Beta 5

Use the stable version :)

@carstenhag I tried what you wrote, and the aar file went to "webpdecoder-2.0.4.12.0" folder (inside the project folder). I switched to beta version of the IDE, and it seems build line you wrote to find it seems incorrect.
Shouldn't it be in "libs" folder or something?
I tried to put it there ("app/libs"), and changed to:

    implementation fileTree(include: ['*.jar','*.aar'], dir: 'libs')

And it still couldn't find stuff from there.
This is what it wrote:

Unresolved reference: webp
Unresolved reference: WebpDrawable
Unresolved reference: loopCount
Unresolved reference: frameIndex
Unresolved reference: start

Adding the line on step 3 of what you wrote (api project(':$PROJECTNAME') ) made it have this issue :

A problem occurred evaluating project ':app'.
> Project with path ':$PROJECTNAME' could not be found in project ':app'.

Well, you need to replace $PROJECTNAME with the name of the project, so webpdecoder-2.0.4.12.0 ;). Also: yes, you can either add libs as "folders" (they are actually projects) or inside a libs folder, doesn't matter if properly set up I think.

@carstenhag I don't understand. Suppose the app name is "Xyz", what should be in build.gradle file, if the created folder is as I wrote ("webpdecoder-2.0.4.12.0" in the project folder, not inside the app's folder)?

@carstenhag OK I think I got it.
I've put the AAR file into the libs folder again, removed the api project, and have this on build gradle file:

    implementation fileTree(include: ['*.jar','*.aar'], dir: 'libs')

    def GLIDE_VERSION = '4.12.0'
    implementation "com.github.bumptech.glide:glide:${GLIDE_VERSION}"
    kapt "com.github.bumptech.glide:compiler:${GLIDE_VERSION}"

It works fine, but for some reason I see this warning :

Warning: Mapping new ns http://schemas.android.com/repository/android/common/02 to old ns http://schemas.android.com/repository/android/common/01
Warning: Mapping new ns http://schemas.android.com/repository/android/generic/02 to old ns http://schemas.android.com/repository/android/generic/01
Warning: Mapping new ns http://schemas.android.com/sdk/android/repo/addon2/02 to old ns http://schemas.android.com/sdk/android/repo/addon2/01
Warning: Mapping new ns http://schemas.android.com/sdk/android/repo/repository2/02 to old ns http://schemas.android.com/sdk/android/repo/repository2/01
Warning: Mapping new ns http://schemas.android.com/sdk/android/repo/sys-img2/02 to old ns http://schemas.android.com/sdk/android/repo/sys-img2/01

Any idea what this is?

Question: what is the new release:
https://github.com/zjupure/GlideWebpDecoder/releases/tag/2.0.4.12.0

Does it mean it has migrated?

Sorry be late to handle this issue. The library has migrated and published to Maven Central at now. (https://search.maven.org/artifact/com.github.zjupure/webpdecoder). As a change, user should change the group id from com.zlc.glide to com.github.zjupure. See README.txt for detail. Thanks.

@zjupure This is the only needed change? Everything else stayed? The package name? Proguard rules ? ...

BTW, why do we have to set Proguard rules? Shouldn't it be as a part of the library?

I think you should change the readme file to show to use "kapt" instead of "annotationProcessor " , because then you can reach your GlideApp class.

@zjupure This is the only needed change? Everything else stayed? The package name? Proguard rules ? ...

BTW, why do we have to set Proguard rules? Shouldn't it be as a part of the library?

I think you should change the readme file to show to use "kapt" instead of "annotationProcessor " , because then you can reach your GlideApp class.

proguard rules is also inline in the aar. kapt is for kotlin and annotationProcessor is for Java.

So it's inside already? So maybe you should update the instructions, as those aren't needed anymore?