| Summary: | Changing JSdoc validator settings causes entire workspace build | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | [WebTools] JSDT | Reporter: | Michael Rennie <Michael_Rennie> | ||||||||
| Component: | General | Assignee: | Michael Rennie <Michael_Rennie> | ||||||||
| Status: | RESOLVED FIXED | QA Contact: | Nitin Dahyabhai <thatnitind> | ||||||||
| Severity: | normal | ||||||||||
| Priority: | P3 | CC: | cmjaun, curtis.windatt.public | ||||||||
| Version: | 3.2 | Keywords: | performance | ||||||||
| Target Milestone: | 3.2.3 | ||||||||||
| Hardware: | PC | ||||||||||
| OS: | Linux | ||||||||||
| Whiteboard: | |||||||||||
| Attachments: |
|
||||||||||
|
Description
Michael Rennie
*** This bug has been marked as a duplicate of bug 317833 *** The exception is a duplicate. The rebuild is standard behavior for all validators, not just JSDT, as far as I know. If you think this behavior should change we should open an Enhancement request. I disagree. How can changing a JS validator setting possibly be rationalized as "ok to build my entire workspace"? A platform example would be how we had to change the API tools builder to not run on all projects that did not contain the API tools nature (for example bugs 221209, 221771). It is extremely important to not run unrelated builders, and like I mentioned for those of us with very large workspaces this severely interrupts our workflow. A fix to this would be to scope your validator build to either the project context (for the property page case) or the "all JS projects in the workspace" context for the workbench pref page case. Then this problem is probably larger in scope than JSDT alone. When I go to the Validation page and change anything at all, it does a full workspace build. Same behavior in JDT. Created attachment 174322 [details]
example patch
Heres a quick patch that scopes your validator to JS projects.
Changing severity. Yes, this is an annoying problem, but it doesn't cause crashes, loss of data, nor a severe memory leak--unless you really mean to focus on the NPE. Which is it? A patch should also invoke the validation builder, org.eclipse.wst.validation.validationbuilder, on projects in which it is set. Otherwise web pages won't have their scripting contents reflect the changes. The Validation builder isn't tied to any natures, though. (In reply to comment #6) > Which is it? The NPE is covered by bug 317833, I included it in this report for completeness. Obviously the focus of this bug is the performance issue, hence the performance tag. (In reply to comment #7) > A patch should also invoke the validation builder, > org.eclipse.wst.validation.validationbuilder, on projects in which it is set. > Otherwise web pages won't have their scripting contents reflect the changes. > The Validation builder isn't tied to any natures, though. That does present more of a problem then. Who provides the Validation builder? JSDT? I noticed it does not get added to a JS project description by default. (In reply to comment #9) > (In reply to comment #7) > > A patch should also invoke the validation builder, > > org.eclipse.wst.validation.validationbuilder, on projects in which it is set. > > Otherwise web pages won't have their scripting contents reflect the changes. > > The Validation builder isn't tied to any natures, though. > > That does present more of a problem then. Who provides the Validation builder? > JSDT? I noticed it does not get added to a JS project description by default. It's part of the Validation Framework in org.eclipse.wst.validation. Created attachment 180081 [details]
Updated patch
Created attachment 180083 [details]
Updated again
Fix checked into 3.2.3 and HEAD. |