bumptech / glide

An image loading and caching library for Android focused on smooth scrolling
https://bumptech.github.io/glide/
Other
34.66k stars 6.13k forks source link

Annotation processor uses class name as package name causing conflicts #2860

Open TWiStErRob opened 6 years ago

TWiStErRob commented 6 years ago

Glide Version: 4.x

Integration libraries: N/A

Device/Android Version: N/A

Issue details / Repro steps / Use case background:

https://github.com/bumptech/glide/blob/eff228fcafc2a3e6077d15d0f2a995edf46f1f56/annotation/compiler/src/main/java/com/bumptech/glide/annotation/compiler/AppModuleProcessor.java#L84

See https://groups.google.com/forum/?utm_medium=email&utm_source=footer#!msg/glidelibrary/ZreirxaqMu0/QGhfJKJoBAAJ

Related: https://github.com/bumptech/glide/issues/2512

Glide load line / GlideModule (if any) / list Adapter code (if any):

package com.example;
class MyApp {
    @GlideModule
    static class MyModule {
    }
}

will generate com.example.MyApp.GlideApp; where MyApp will be a package and this conflicts with the outer class from the app.

dingfengnupt commented 6 years ago

I have the same question if use compiler. annotationProcessor 'com.github.bumptech.glide:compiler:4.6.1'

TWiStErRob commented 6 years ago

@dingfengnupt just move the module outside until this issue is fixed.

hanlyjiang commented 6 years ago

Same issue, The Chinese document use Application ,so I think it is ref to Application Class, actually the doc's Application is an module type , another is library module ,the application module result in an apk, and the library module result in an aar/jar

So just move it out the Application class

sjudd commented 6 years ago

This shouldn't be too bad to fix if anyone is interested, the package name that Glide uses is set here: https://github.com/bumptech/glide/blob/b7c2b1360c777794c50351a10c30c08a3390b753/annotation/compiler/src/main/java/com/bumptech/glide/annotation/compiler/AppModuleProcessor.java#L84.

Probably could just change the package name to match the enclosing package name. There'd be some limited risk of collisions given that we'd be dropping the parent class names. Another option is to just assert that the modules aren't inner classes.