I've found that this was actually caused by jglick's: http://hg.netbeans.org/main/rev/a051a7599f2d

My change was months ago, something must have been broken since then.

I'll have a look. In any case, the build job for ruby-main is passing (and so are other jobs), so seems that something 
in main broke this.

I don't know what was causing this, but trunk seems to be back to stable for some time already. The same test never 
failed in ruby-main, and the shadows in rubyproject seem fine to me.

Reopening as the test is failing again in trunk.

I can't see anything wrong in ruby.rubyproject, as I wrote earlier the shadows seem fine to me and the test is failing  
in trunk only. Moreover it is failing seemingly randomly. Shouldn't be a dependency problem either as 
javascript.editing is in the IDE cluster. 

Reassigning to ide/commit validation for further evaluation.

Happens again:
http://deadlock.netbeans.org/hudson/job/trunk/6042/testReport/org.netbeans.core.validation/ValidateLayerConsistencyTest/testValidShadows/

And prevents from propagation of important fixes into daily build!

PLEASE FIX!

#6043 passed, with no obviously related fix. Seems random? Key error is

org.netbeans.InvalidException: StandardModule:org.netbeans.modules.javascript.editing jarFile:
/hudson/workdir/jobs/trunk/workspace/nbbuild/netbeans/ide11/modules/org-netbeans-modules-javascript-editing.jar: Layer
not found: org/netbeans/modules/javascript/editing/layer.xml

I suspect some problem in javascript.editing/build.xml#jar (which uses <csljar>). The build log in #6042 shows

javascript.editing.jar:
Building jar:
/hudson/workdir/jobs/trunk/workspace/nbbuild/netbeans/ide11/modules/org-netbeans-modules-javascript-editing.jar
   Handling text/javascript
   Handling text/x-json
Exception in thread "AWT-EventQueue-0" java.lang.NullPointerException: Null path encountered in [null] of type
JavascriptBootClassPath
        at org.netbeans.api.java.classpath.GlobalPathRegistry.register(GlobalPathRegistry.java:188)
        at org.netbeans.modules.javascript.editing.JsLanguage$1.run(JsLanguage.java:92)
        at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:209)
        at java.awt.EventQueue.dispatchEvent(EventQueue.java:597)
        at java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:269)
        at java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:184)
        at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:174)
        at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:169)
        at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:161)
        at java.awt.EventDispatchThread.run(EventDispatchThread.java:122)

Why javascript.editing module code is running during its own JAR creation, why this code is running on EQ, and why an
uncaught exception fails to halt the build - I don't know. javascript.editing module owner (vstejskal? mfukala?
jjancura?) please evaluate.

"Why javascript.editing module code is running during its own JAR creation" - Decent men don't use language that would
be required to comment on this :-)

"why this code is running on EQ" - What is running in EQ is a task launched by JsLanguage constructor. JsLanguage is
instantiated from CslJar, see above.

"and why an uncaught exception fails to halt the build" - I only guess here, but most likely because it's thrown in the
AWT thread, which is not the one running ant tasks and performing the build.

Marek is on holiday, so I'll fix it somehow.

This will hopefully fix it - http://hg.netbeans.org/jet-main/rev/ed4c37762f91

Integrated into 'main-golden', will be available in build *200906190201* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)
Changeset: http://hg.netbeans.org/main-golden/rev/ed4c37762f91
User: Vita Stejskal <vstejskal@netbeans.org>
Log: #166635 - do nothing when JsLanguage is instantiated from CslJar task during the build

*** Issue 167050 has been marked as a duplicate of this issue. ***

v.