You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository was archived by the owner on Feb 26, 2023. It is now read-only.
Repository navigation
This repository was archived by the owner on Feb 26, 2023. It is now read-only.
Do not print additional info in compilation messages #849
I think since the newly introduced logger, the compilation error/warning messages are displayed like this:
00:53:54.418 [Worker-253] ERROR o.a.h.AnnotationHelper:110
- @org.androidannotations.annotations.Bean cannot be used on a private element
I think all information except the message after the dash is totally unnecessary to print, it does not help the programmer to resolve the compilation problem. Moreover, this additional information draws the attention away from the real issue.
I understand your point. But this feature was added because of a huge amount of issues without any information to help us nor the stack trace. Also lots of issues are just duplicate because nobody takes the time to check if the issue already exists or not..
Unless Github provide a way to add an instruction message in new issue page I think we should keep this to not lose more time with these incomplete issues.
But we could rethink the message format if you have any proposition.
I do not understand your point. This is a normal error message. These additional information should only be printed when AA crashed. Maybe i misunderstood you? :S
Ho sorry. I think I misunderstood your initial request... You're talking about the compilation logs and not crash logs.
The first part of the message 00:53:54.418 [Worker-253] ERROR o.a.h.AnnotationHelper:110 is a common logging format. As each log is appended in the same log file, at each incremental annotation processing (ie each file saved), the is lots of logs written in the file. So, the hour could be really helpful to retrieve the right log and help the developer to know what's going on.
Also, the source of the log call help US sometime to know which AA version (mainly if the user uses a snapshot) is using.
But, I agree the current thread could be removed :)
Eventually we could use different format according to the appender :
FileAppender : hour thread level class - message
ConsoleAppender : level class - message
MessagerAppender : level class - message
More importantly, the ConsoleAppender is activated by default in 3.0 due to a bug. It'll be fixed in the 3.0.1 hotfix
Ok, I see. (Damn it's hard to think after the new year party xD)
Compilation messages in IDE are handled by MessagerAppender. You're right, for this one we should remove some info as there are already provided by the IDE. So the only relevants parts are the following: class+line and message. Should we keep both or just the message ?
I think we should just keep the message. It is totally irrelevant to a non-AA developer which generator class is responsible for that message and on which line exactly. Moreover it draws the attention away from the real issue and it can confuse beginner programmers. So for the IDE compilation messages, the pre-3.0 behavior is the best i think.
No problem, and i wish a Happy New Year for the entire AA community. :)
Activity
DayS commentedon Dec 31, 2013
I understand your point. But this feature was added because of a huge amount of issues without any information to help us nor the stack trace. Also lots of issues are just duplicate because nobody takes the time to check if the issue already exists or not..
Unless Github provide a way to add an instruction message in new issue page I think we should keep this to not lose more time with these incomplete issues.
But we could rethink the message format if you have any proposition.
WonderCsabo commentedon Dec 31, 2013
I do not understand your point. This is a normal error message. These additional information should only be printed when AA crashed. Maybe i misunderstood you? :S
DayS commentedon Jan 1, 2014
Ho sorry. I think I misunderstood your initial request... You're talking about the compilation logs and not crash logs.
The first part of the message
00:53:54.418 [Worker-253] ERROR o.a.h.AnnotationHelper:110is a common logging format. As each log is appended in the same log file, at each incremental annotation processing (ie each file saved), the is lots of logs written in the file. So, the hour could be really helpful to retrieve the right log and help the developer to know what's going on.Also, the source of the log call help US sometime to know which AA version (mainly if the user uses a snapshot) is using.
But, I agree the current thread could be removed :)
Eventually we could use different format according to the appender :
More importantly, the ConsoleAppender is activated by default in 3.0 due to a bug. It'll be fixed in the 3.0.1 hotfix
WonderCsabo commentedon Jan 1, 2014
I am aware of this format. Maybe i should clarify what i think.
The .log file is OK with this format, it helps debugging etc., i totally understand the reason and i think it is a good thing.
But the compilation messages which appears in various elements of the client code in the IDE itself should not contain the additional info.
DayS commentedon Jan 1, 2014
Ok, I see. (Damn it's hard to think after the new year party xD)
Compilation messages in IDE are handled by
MessagerAppender. You're right, for this one we should remove some info as there are already provided by the IDE. So the only relevants parts are the following: class+line and message. Should we keep both or just the message ?WonderCsabo commentedon Jan 1, 2014
I think we should just keep the message. It is totally irrelevant to a non-AA developer which generator class is responsible for that message and on which line exactly. Moreover it draws the attention away from the real issue and it can confuse beginner programmers. So for the IDE compilation messages, the pre-3.0 behavior is the best i think.
No problem, and i wish a Happy New Year for the entire AA community. :)
DayS commentedon Jan 1, 2014
I guess you're right. I'll push a PR very soon.
DayS commentedon Jan 1, 2014
Fixed. I'll wait a few more days before releasing the 3.0.1 hotfix