Repro:
4.1.0gradlew assembleDebugWarning output:
WARNING: Module 'com.github.bumptech.glide:glide:4.1.0' depends on one or more Android Libraries but is a jar
WARNING: Module 'com.github.bumptech.glide:glide:4.1.0' depends on one or more Android Libraries but is a jar
WARNING: Module 'com.github.bumptech.glide:glide:4.1.0' depends on one or more Android Libraries but is a jar
WARNING: Module 'com.github.bumptech.glide:glide:4.1.0' depends on one or more Android Libraries but is a jar
You can slap a qualifier on the dependency, I think: ...:4.1.0@aar
Thanks. com.github.bumptech.glide:glide:4.1.0@aar works and removes the warning. I made a PR to update the README.md here: https://github.com/bumptech/glide/pull/2319.
I wonder what conditions bring this up. I don't remember having this problem before.
@sjudd maybe there's no point publishing the jar any more. I guess before AAR wasn't widely supported, and the JAR artifact is a legacy of that?
Looks like it. AAR comes from: https://github.com/bumptech/glide/blob/master/library/build.gradle and its "main" package is the JAR: https://github.com/bumptech/glide/blob/master/glide/gradle.properties#L3.
We should just publish the project as an AAR.
It needs to be:
compile('com.github.bumptech.glide:glide:4.1.0@aar') {
transitive = true;
}
Need the transitive = true; otherwise it won't pull in the annotations module which contains @GlideModule.
The aar dependency is probably the new componentized support libraries. I can probably just revert that for the next version. It's not a big deal to publish as AAR though. It would fix the view id conflict with ViewTarget.
The reason it's published as a jar is simplicity (not so much of an issue now that everything is using gradle) and because aars didn't used to be supported.
What's more convenient for everyone?
Aah, I remember now. I think we can keep using JAR published, but support-fragment probably needs to change from compile to provided. That may solve the issue of this warning as well as downgrading the support version.
This may require the new (3.x) Gradle plugin to actually work, long time since played around.
As far as I remember, an AAR library depending on another AAR with compile repackages everything, so the merger takes a lot of time, that's why provided works well.
I believe this is fixed, if someone can verify using the Snapshot, I'd appreciate it.
@sjudd Thanks. The 4.2.0-SNAPSHOT works!
@jaredsburrows I guess you just noticed the repositories ;)
@TWiStErRob I saw the sjudd added this to the 4.1.1 milestone. So assumed 4.1.1-SNAPSHOT since 4.1.0 release is out. So I just manually made sure I had the latest Snapshot: 4.2.0-SNAPSHOT.
Ah, tricky versions... thanks for checking!
I am facing the same issue in version 4.4.0. Should I downgrade to some lower version?
Ugh yeah I meant to change this to aar.
Does this actually break? Or just warn?
Actually this is already done: https://github.com/bumptech/glide/blob/b4b45791cca6b72345a540dcaa71a358f5706276/library/gradle.properties.
Do all AAR libraries require you to specify @aar? Or more likely this is insufficient.
http://central.maven.org/maven2/com/github/bumptech/glide/disklrucache/4.4.0/disklrucache-4.4.0.pom
And
http://central.maven.org/maven2/com/github/bumptech/glide/glide/4.4.0/glide-4.4.0.pom
Are missing any mention of packaging, jar, or aar, despite differing values in gradle.properties.
Huh and I actually don't see the warning at all in a sample project: https://github.com/sjudd/Base64ModelLoaderExample.
I did find a way to get packaging into the pom, but unless someone tells me this breaks something, we'll fix in in 4.5
Most helpful comment
It needs to be:
Need the
transitive = true;otherwise it won't pull in theannotationsmodule which contains@GlideModule.