androidannotations.log file constantly grows

[VictorAlbertos]

Hi!

I’ve been working with this framework for a while and I've never encountered this problem before:

The "androidannotations.log" file constantly grows,

and the tasks “:app:assembleDebug” never finishes and the file gets more and more heavy (3 gigas!).

I will go to my previous commit -before this mess happened, and see what might be causing this problem.

Any thoughts?

[WonderCsabo]

This is the normal behavior. You can reduce the verbosity of the log file or completely disable it (since 3.3). But eventually it will go away at the first project cleaning.

[WonderCsabo]

Sorry, for some reason i skipped this part

tasks “:app:assembleDebug” never finishes

This is a problem, it seems the annotation processing made into an infinite loop. Please check your changes, we have to investigate this.

[VictorAlbertos]

Ok, I will focus on finding why "tasks ':app:assembleDebug' never finishes" ;)
Thanks!

[VictorAlbertos]

I’ve found the problem: creating an static class inside an abstract class breaks the annotation processing:

@EBean
public abstract class WhoIsTheBug {

    @EBean
    public static class ImTheBug {
        public void testMe() {
            Log.d("hello", "hello");
        }
    }

}

Without using enhances annotations, I will instantiate this class like this:

WhoIsTheBug.ImTheBug instance = new WhoIsTheBug.ImTheBug();
instance.testMe();

Do you know why this happens?

[WonderCsabo]

Great, i can repro with Eclipse and gradle, thanks for the minimal example!

I will debug this. BTW, @yDelouis do you have any idea? I think you worked on inner classes.

[yDelouis]

There is a while loop in the processor for processing enclosing class before the inner class. And the loop stops when everything is generated.
The problem is that in case of an abstract class, we doesn't generate the subclass, so we never generate the inner class subclass and the loop never stops.

To fix this, we can generate subclass for abstract classes (which has already been discussed) or prevent inner class in abstract class.

[WonderCsabo]

I see, it makes sense. I do not think we should break the convention of not generating subclasses for abstract classes. I think we should invalidate in this case.

[WonderCsabo]

@yDelouis WDYT?

[yDelouis]

I agree.

[WonderCsabo]

@yDelouis if you do not mind i assigned it to you as you worked on the inner classes generation.

[yDelouis]

Ok.

[WonderCsabo]

I take this over.