Stop hiding warnings via during builds

[vogella]

The adaption of pomless builds is harder as multiple pom files contains <code.ignoredWarnings>-warn:-deprecation,raw,unchecked</code.ignoredWarnings>. IIRC these are used to hide warnings. What is the value of hidding warnings? Any additional warnings added to such plug-ins will not be visible.

I vote for removing these entries.

cc @akurtakov @HannesWell

[laeubi]

@vogella I tried to convert this to a "Poll" discussion, do you see any option to add poll items as an author?

Beside that I think there was recently a discussion and the concern was that maybe people get mad when seeing much (new) warnings in the build.

[vogella]

do you see any option to add poll items
No

Beside that I think there was recently a discussion and the concern was that maybe people get mad when seeing much (new) warnings in the build.

Except that these are not new warnings, they are hidding warnings. I understand that some people prefer to not see existing warnings but I don't think that is a valid reason to make the build more complex and to make it impossible to spot new introduced warnings.

But lets see what other people think / say. Do you have an opinion here @laeubi ?

[laeubi]

Except that these are not new warnings, they are hidding warnings.

Sure I just summarize from the last discussion maybe @HannesWell remember the issue?

Do you have an opinion here @laeubi ?

We should not hide the warnings, so +1 for removing any supression / customaization on the bundle level...

[HannesWell]

Except that these are not new warnings, they are hidding warnings.

Sure I just summarize from the last discussion maybe @HannesWell remember the issue?

Sorry, I don't remember the exact issue/PR anymore, it was likely somewhere in PDE or Equinox.
But the arguments where summarized here already that too many warnings make it harder to spot new warnings. Of course that also has the danger that actual new warnings are suppressed.

[akurtakov]

I'm also for removing these but also want to ask whoever does it to keep an eye on I-builds (e.g. https://download.eclipse.org/eclipse/downloads/drops4/I20220612-1800/testResults.php#PluginsErrors ) and fix warnings after that .
I've been the one trying to keep this table empty for quite some time so we don't regress in some areas at least but if we don't keep these to zero they will just keep growing.

[laeubi]

https://plugins.jenkins.io/warnings-ng/ has an option to set a barrier before the build is marked as UNSTABLE regarding warnings, so one could use current warning count here, and lower the barrier on each release (where we hopefully have less warnings than before).

[akurtakov]

The table I pointed to makes sure we do not regress in bundles that do not hide warnings. All I ask is that once one removes the hiding (VERY WELCOME!) to try and spend some time to actually fix these warnings.

[akurtakov]

https://plugins.jenkins.io/warnings-ng/ has an option to set a barrier before the build is marked as UNSTABLE regarding warnings, so one could use current warning count here, and lower the barrier on each release (where we hopefully have less warnings than before).

If this plugin can make sure that warnings number doesn't increase compared to latest master build that would be perfect as it would make sure our baseline will drop with every fixed warning automatically.

[laeubi]

@akurtakov I recently seen a GH action that parses code metrics and warns if there are more warnings, one even might enforce to remove at least any warnings from changed lines... GH supports "Annotations" for tha and we might can create an action that even detects all the FIXME, TODO, ... just as an inspiration:
https://github.com/pushtorefresh/javac-warning-annotation

[laeubi]

It could even bee configured to report back to GH:

https://github.com/jenkinsci/warnings-ng-plugin/blob/master/doc/Documentation.md#warnings-checks-for-github-projects

@vogella do you like to try enable this and probably request permissions from the Eclipse-Infra so we can enable this for the platform Jenkins verification builds?

[HannesWell]

I'm also in favor of removing the suppression but agree that at the same time (ideally with the same commit) the warnings that are not suppressed anymore should be fixed in the code. Ideally by really fixing it (e.g. replacing deprecated code, add generic type parameters, etc.) or as last resort by suppressing the warning in the code (happens often for the access restriction warnings due to references to 'internal' code).

I already did this a few times and have the intention to do it more often if I can, but there is much more to do, so any help is welcome. :)

[laeubi]

I now asked for using Equinox as an incubator for the warnings-github plugin:

https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/issues/1422

[laeubi]

@tjwatson can you please give +1 on the helpdesk issue?

[jukzi]

ignoredWarnings has been removed.