Bug 319884 - Changing JSdoc validator settings causes entire workspace build
Summary: Changing JSdoc validator settings causes entire workspace build
Status: RESOLVED FIXED
Alias: None
Product: JSDT
Classification: WebTools
Component: General (show other bugs)
Version: 3.2   Edit
Hardware: PC Linux
: P3 normal (vote)
Target Milestone: 3.2.3   Edit
Assignee: Michael Rennie CLA
QA Contact: Nitin Dahyabhai CLA
URL:
Whiteboard:
Keywords: performance
Depends on:
Blocks:
 
Reported: 2010-07-14 12:59 EDT by Michael Rennie CLA
Modified: 2010-10-01 15:18 EDT (History)
2 users (show)

See Also:


Attachments
example patch (3.80 KB, patch)
2010-07-14 14:07 EDT, Michael Rennie CLA
no flags Details | Diff
Updated patch (2.67 KB, patch)
2010-10-01 15:09 EDT, Chris Jaun CLA
no flags Details | Diff
Updated again (2.75 KB, patch)
2010-10-01 15:17 EDT, Chris Jaun CLA
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Michael Rennie CLA 2010-07-14 12:59:04 EDT
build: 1.2.0.v201006041342-7C78FGDF9JgLWLMLM4Vsye

Steps:

change a validator setting in the Validator -> JSdoc pref page and hit ok

Expected 

any JS files in JS projects would be re-validated with the new settings

Happens 

watch as your entire workspace is rebuilt!! 

Changing the validator settings caused all builders to run on my very large workspace, including the Java builder, PDE builder and API Tools, all of which have nothing to do with the validator.

Also 75% of the way through the build an NPE is thrown which causes the entrie build to fail, leaving projects in a half-built state, which requires another clean + full build to fix.

The NPE mentioned:
java.lang.NullPointerException
	at org.eclipse.wst.jsdt.internal.compiler.flow.UnconditionalFlowInfo.markAsDefinitelyNonNull(UnconditionalFlowInfo.java:1186)
	at org.eclipse.wst.jsdt.internal.compiler.ast.FieldReference.analyseAssignment(FieldReference.java:80)
	at org.eclipse.wst.jsdt.internal.compiler.ast.Assignment.analyseCode(Assignment.java:59)
	at org.eclipse.wst.jsdt.internal.compiler.ast.CompilationUnitDeclaration.analyseCode(CompilationUnitDeclaration.java:155)
	at org.eclipse.wst.jsdt.internal.compiler.Compiler.process(Compiler.java:589)
	at org.eclipse.wst.jsdt.internal.compiler.Compiler.compile(Compiler.java:347)
	at org.eclipse.wst.jsdt.internal.core.builder.AbstractImageBuilder.compile(AbstractImageBuilder.java:286)
	at org.eclipse.wst.jsdt.internal.core.builder.BatchImageBuilder.compile(BatchImageBuilder.java:86)
	at org.eclipse.wst.jsdt.internal.core.builder.AbstractImageBuilder.compile(AbstractImageBuilder.java:225)
	at org.eclipse.wst.jsdt.internal.core.builder.BatchImageBuilder.build(BatchImageBuilder.java:58)
	at org.eclipse.wst.jsdt.internal.core.builder.JavaBuilder.buildAll(JavaBuilder.java:291)
	at org.eclipse.wst.jsdt.internal.core.builder.JavaBuilder.build(JavaBuilder.java:194)
	at org.eclipse.core.internal.events.BuildManager$2.run(BuildManager.java:629)
	at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42)
	at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:172)
	at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:203)
	at org.eclipse.core.internal.events.BuildManager$1.run(BuildManager.java:255)
	at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42)
	at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:258)
	at org.eclipse.core.internal.events.BuildManager.basicBuildLoop(BuildManager.java:311)
	at org.eclipse.core.internal.events.BuildManager.build(BuildManager.java:343)
	at org.eclipse.core.internal.resources.Workspace.build(Workspace.java:344)
	at org.eclipse.wst.jsdt.internal.ui.util.CoreUtility$BuildJob.run(CoreUtility.java:150)
	at org.eclipse.core.internal.jobs.Worker.run(Worker.java:54)
Comment 1 Chris Jaun CLA 2010-07-14 13:11:04 EDT

*** This bug has been marked as a duplicate of bug 317833 ***
Comment 2 Chris Jaun CLA 2010-07-14 13:12:59 EDT
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.
Comment 3 Michael Rennie CLA 2010-07-14 13:24:24 EDT
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.
Comment 4 Chris Jaun CLA 2010-07-14 13:59:46 EDT
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.
Comment 5 Michael Rennie CLA 2010-07-14 14:07:03 EDT
Created attachment 174322 [details]
example patch

Heres a quick patch that scopes your validator to JS projects.
Comment 6 Nitin Dahyabhai CLA 2010-07-14 14:23:52 EDT
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?
Comment 7 Nitin Dahyabhai CLA 2010-07-14 14:26:47 EDT
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.
Comment 8 Michael Rennie CLA 2010-07-14 14:43:25 EDT
(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.
Comment 9 Michael Rennie CLA 2010-07-14 14:45:52 EDT
(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.
Comment 10 Nitin Dahyabhai CLA 2010-08-26 13:05:29 EDT
(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.
Comment 11 Chris Jaun CLA 2010-10-01 15:09:57 EDT
Created attachment 180081 [details]
Updated patch
Comment 12 Chris Jaun CLA 2010-10-01 15:17:42 EDT
Created attachment 180083 [details]
Updated again
Comment 13 Chris Jaun CLA 2010-10-01 15:18:42 EDT
Fix checked into 3.2.3 and HEAD.