Community
Participate
Working Groups
Build Identifier: org.eclipse.wst.validation_1.2.201.v201101270100.jar, org.eclipse.wst.validation.ui_1.2.204.v201004150700.jar If I set the project-level validator preferences/properties on a particular project, I expect the settings to stay regardless of the global settings. I'm witnessing behaviour where my local settings are only partially saved, and a validator is enabled after changing the workbench-level preferences. Reproducible: Always Steps to Reproduce: 1.Open a new workspace 2.Go to the workbench preferences, go to the "Validation" page 3.Disable all validators and press OK 4.Create an EJB project (I created only the EJB project) 5.Open the properties on the EJB project, go to the "Validation" page 6.Click on the "enable project specific setting" checkbox Problem #1: What are these defaults? Why are all those validators selected by default? The global preferences are set to disable all validators, so I'd expect that to be the default here, and let me customize from that baseline. 7.Click Disable All button 8.Check "EJB Validator" in both Manual and Build columns 9.Click OK 10.Bring up the properties of the EJB project again, go to the validation page Problem #2: The setting I just made is not saved. The EJB Validator is not checked. 11.Check the columns again, press OK 12.Bring up the properties page again, this time the setting stayed. Press cancel. 13.Bring up the workbench-level validation preference page. 14.Select the WSDL Validator to run both manual and during build 15.Press OK. 16.Go back to the project-level settings for the EJB project 17.Note that the WSDL Validator is added, yet I had explicitly set up the validators I wanted to run on that project. I expect that my settings are not changed.
Was the preference to allow projects to override the workspace preferences enabled?
Here's an even more baffling outcome: 1.Open with a new workspace 2.turn off all validators globally 3.create EJB project 4.set project-level validators to only "EJB Validator" (do it two times so it actually gets set) 5.go back to global preference, enable all validators, press OK 6.open the validation properties page on the EJB project Problem #1: Note that many validators are now enabled, as witnessed in the other steps. The behaviour seemed to suggest some sort of union logic was being done (which I wouldn't agree with), but now I see that some of the validators are enabled and some are not. For example, the WS-I Message Validator that was enabled globally is not checked, unlike many of the others. 7.Cancel the project properties dialog 8.Disable all validators globally 9.Open project properties again. Note that original settings are seen (only EJB validator is enabled) 10.Go back to the global properties, enable all validators 11.Open project-level settings and check the ones that are not currently checked 12.Go back to the global properties, disable all validators 13.Open project-level settings and see that the manually changed ones are checked, but not the others
Was the preference to allow projects to override the workspace preferences enabled? >yes, the global preference was set to allow projects to override.
Rosendo, can you take a peek?
I agree that this is confusing and has some problems. A large part of the confusion, comes from our attempt to "seamlessly" support new validators. We wanted to support this use case: 1) I turn off the ABC validator for project XYZ. 2) At some point in the future, I upgrade to a newer version of the product, and this introduces a new DEF validator. Or instead, I install a new component and it introduces a new DEF validator. 3) Which validators should now run on project XYZ? The ABC validator should not run because it was manually turned off, but the new DEF validator should start with the default settings that the validator developer set for it. That is if the developer thought that it should be on by default it should run, and if they thought it should be off by default then it shouldn't run. To support this, we had the idea of storing just the delta change at the project level. Then as new validators appeared, they would run as the vendor intended. (In addition to the on/off settings, there are lots of other settings as well (like various filters)) But I think the interaction between these project level deltas and the workspace settings need to be sorted out. If the user went to the trouble of setting project level settings, these should normally take precedence over workspace settings, and the fact that they are not is a problem.
