Community
Participate
Working Groups
I would like to set the severity of some compiler warnings to info. I can only set it to error warning or ignore. If I set it to ignore then it doesn't show in my problems view!
Why aren't you simply leaving these as warnings ?
There are far too many warnings! If there are time constraints on your developement there should be some compiler warnings that can be ignored for example javadoc warnings. If you want to create a jar you have the option of not including files with warnings I cannot use that feature because 95% of my files have javadoc warnings.
If you are not interested in certain warnings, then why don't you simply turn them off ?
I never said I wasn't interested in them. I said that under certain circumstances they can be ignored. We all know that we should ideally comment our code immaculately but sometimes we don't have enough time to do so!
I see what you mean. We indeed do not use the INFO severity from IMarker, also we don't use the various priorities (need to check with UI if this would be relevant).
Nick: currently, Java problems do not play with priorities. Would there be some benefit as to using HIGH/NORMAL/LOW in combination with severities ? Priorities could serve as subcategories, and the Java compiler could emphasize certain type of errors using priorities. For instance, all optional problems raised as errors could be considered as LOW priority, and most type/import errors could be promoted as HIGH (since likely to account for many secondary ones). Is the problem view allowing to sort on a combination of these ? SEVERITY+PRIORITY ?
The Problems view currently only sorts on severity. According to the core marker extension definitions, priority applies only to Task markers, not Problem markers. If we want to define finer grained severities, then I think we need to nail down the semantics of this, and extend the core marker definitions appropriately. I don't think we should overload Task priority. I think if we were going to give finer grained severities to problems, we may also want a clearer visual distinction betweeen them in the Problems view. If there is no visual indication, then it would be hard to explain the resulting sort order. This may not be necessary though. It may suffice to have the order be "intuitively correct" but reveal the details in the marker Properties dialog. In any case, I don't see how this would solve Nikolay's problem with how the Jar exporter treats warnings. On the other hand, I don't really understand how that "exclude classes with warnings" option is useful anyway. When would you ever want to check this?
I was envisaging tagging certain categories of problem with a higher priority (import problems for instance). Visually, they would all have a similar message. I suspect having the nuance between INFO and WARNING allows a picky user to not want to ship some code with certain style issues, but still see all less important diagnosis... One could argue that he should simply raise the priority of these warnings to ERROR, and leave the other ones as WARNING and disable the check on export for warnings...
Created attachment 6951 [details] Patch to check priority after severity If you'd like to experiment with finer-grained severities, this patch has a change to M5's ProblemView.java to sort by priority after severity in the default sort order. With this patch, the default sort order is: SEVERITY (descending), PRIORITY (descending), // new FOLDER (ascending), RESOURCE (ascending), LOCATION (ascending), DESCRIPTION (ascending), CREATION_TIME (ascending) Note that if you change the sort order by clicking on different column headers, you will lose the ability to sort by severity then priority. Closing the view (in all perspectives in the same window) and then reopening it will restore the default sort order. A real solution would have to address this problem.
Kent - what do you think about using PRIORITY in combination with SEVERITY ? We could revive the #secondary bit for problems... these would use the LOW priority, then the import/hierarchy problems would get the HIGH priority... Thoughts ?
I think its too complicated. Adding the Info option for javadoc problems, NLS and other minor warnings is enough. Then I could filter info problems from the Problems View.
Right, but what about the case I have something broken (Statement hierarchy) and tons of secondary problems due to it. Can we improve the problem sorting and make the big problem stand first ?
I would rather have something above ERROR to handle those cases... such as REAL_BAD_ERROR! Maybe the icon could be a flaming red fireball instead of a bland red X. ;)
also see bug 38718 and bug 38988
+1 for comment 11 (adding INFO severity for compiler problems -> can be filtered in Problems view)
Will reconsider post 3.0
Removing milestone of deferred item.
Could this be reconsidered for 3.1? My use case is this: - Error: errors which prevent a build from running (JLS violations) - Warning: things which should not be present in the product / in CVS (unused imports, other severe style violations) - Info: bad style, only interesting when editing the CU (empty statement, unqualified access to instance field, ...) Currently, I have to set info problems to 'Warning'. But then, I get too many warnings, such that I have to set some warnings to 'Error' for not missing them. But setting e.g. Unused imports to 'Error' prevents me from using hot code replace, since the compiler then generates code to throw run-time exceptions. -> I'm out of luck:-(
*** Bug 69808 has been marked as a duplicate of this bug. ***
As of now 'LATER' and 'REMIND' resolutions are no longer supported. Please reopen this bug if it is still valid for you.
Reopening as this makes perfect sense in the context of apt.
Will be fixed as bug 342600. *** This bug has been marked as a duplicate of bug 342600 ***
*** This bug has been marked as a duplicate of bug 83548 ***
