Add preference to change severity for missing project specific encoding

ingomohr commented 2 years ago

Introduces a new preference that enables to specify if and using which severity markers shall be added in case of missing project-specific encoding settings.

This is the PR of the fork for issue #166

Todo

@merks I could use some help/hints w/ further unit tests. ** i.e. where am I supposed to integrate tests for this? Can I add an extra test class just for this?
@merks Maybe you have an idea for this: I cannot seem to delete the "project encoding" markers. If I delete them, the pref change listener re-creates them right away, so that to the user this has the effect of "not deleted at all" * I checked the event type, the build kind and the delta type - but they're all exactly the same for both cases: ** I delete the marker from the Problems view *** I re-build (or clean and rebuild) the projects on the workspace What I want is to be able to delete the markers - and then have a project-rebuild re-add the markers again. Turning off "on access refresh" had no effect here. I'm out of ideas atm.

Here's what I did

Change

Added the preference with a default value (which is WARN (as it was the severity before)
Added a pref change listener as a service to remove/add/update the markers accordingly
Added a severity provider class b/c I need access to the severity in both the new pref change listener I added and the existing ValidateProjectEncoding class
Tested that provider using Mockito (which I added to the dependencies of the resources test fragment) ** Since I cannot mock a static constant (static methods can be mocked w/ Mockito, but constants apparently can't), I decided to use the same package for the test class so that I can override the "package-protected" getter for the InstanceScope.

Manual Integration Test

Tested w/ my fork of eclipse.platform.ui
Modifying the severity (except "ignore") updated the markers as expected
Modifying the severity to "ignore" removed the markers as expected
Modifying the severity from "ignore" to something else added the markers were needed

Thank you in advance for having a look at the PR!

Kind regards Ingo

trancexpress commented 2 years ago

I'm not sure I fully understand you here. I never heard of plug-in customization for preferences before. I updated the commit message (I hope) accordingly.

Commit message is fine now.

The plug-in customization file (can be passed with the mentioned argument) contains preferences that you would like Eclipse to set on "start-up". The preference values in the file act as defaults and can still be changed by the user. See e.g.: https://www.eclipse.org/eclipse/platform-core/documents/user_settings/plugin_customization.html

ingomohr commented 2 years ago

I'm not sure I fully understand you here. I never heard of plug-in customization for preferences before. I updated the commit message (I hope) accordingly.

Commit message is fine now.

The plug-in customization file (can be passed with the mentioned argument) contains preferences that you would like Eclipse to set on "start-up". The preference values in the file act as defaults and can still be changed by the user. See e.g.: https://www.eclipse.org/eclipse/platform-core/documents/user_settings/plugin_customization.html

Thanks for the info! We certainly can use that learning with our Eclipse-based products, too. :)

eclipse-releng-bot commented 2 years ago

The Jenkins build of this PR has now completed. See details at https://ci.eclipse.org/platform/job/eclipse.platform.resources/job/PR-167/19/

ingomohr commented 2 years ago

@trancexpress I think I resolved/answered all your feedback now. (The PR's readability starts to become a little bit complicated ;) ). This is just the info for you that I don't have any local changes left that I plan to push.

trancexpress commented 2 years ago

Can be merged from my POV, with the respective change in platform UI.

ingomohr commented 2 years ago

Can be merged from my POV, with the respective change in platform UI.

Thanks for your feedback! Appreciate it.

merks commented 2 years ago

@iloveeclipse Have all your change requests been addressed?

iloveeclipse commented 2 years ago

@iloveeclipse Have all your change requests been addressed?

Yes, thanks.

But I'm already working on the 16th (yes, 16th) Pull Request build for this feature

So what? I've seen reviews with over 50 rounds or three years. Only the sky is the limit:-)

ingomohr commented 2 years ago

@merks @laeubi @iloveeclipse @trancexpress Thank you all for your feedback and the discussions!

Even though this felt like "quite a ride" (maybe not only to me), I think we added some nice value here.

And maybe future contributions will go a little bit smoother, too. 😊

eclipse-platform / eclipse.platform.resources