This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
A module suite will be broken semi-permanently after running once with module disabled which breaks corebridge - only fix is to delete the user dir, but the clean target doesn't do that. Here's the specific problem: Create a do-nothing module and add it to a suite. Disable all clusters except platform6. Disable everything in platform6 except: org.openide.actions org.openide.util org.openide.modules org.openide.filesystems org.netbeans.bootstrap/1 org.openide.options org.netbeans.modules.queries/1 org.netbeans.modules.masterfs/1 org.netbeans.swing.plaf org.netbeans.core.startup/1 Run the suite. It runs fine. Now open the suite properties, and disable org.openide.actions Run the suite again. Part way through startup, you will see: java.lang.AssertionError: Bridge has to be registered at org.netbeans.core.startup.CoreBridge.getDefault(CoreBridge.java:29) at org.netbeans.core.startup.Main.initUICustomizations(Main.java:172) at org.netbeans.core.startup.Main.start(Main.java:366) at org.netbeans.core.startup.TopThreadGroup.run(TopThreadGroup.java:90) at java.lang.Thread.run(Thread.java:608) and the run will hang during startup. You have to kill the process - there's no way to kill it now from the IDE, and you cannot run again until you kill it). Now open the suite properties, and reenable org.openide.actions It hangs with the same assertion error on startup. Try the "Clean All and Build" target on the suite. It does not help. The only way to escape from this cul-de-sac is to clean the suite, and then manually delete suite/build/testuserdir from a shell. A simple fix would be to have the clean target for a suite delete the test user dir. See also issue 66796
Forgot to set priority - a user can easily, innocently get their application into an unrunnable state, with no way to get out of that state from the UI.
I get the assertion error with the moduleconfig you list, even with actions API on. When I get the error, yes I have to kill the process from a shell. Build | Stop Building is not enough for whatever reason. Not much to do about it - Java's process control sucks. After the process is killed, Clean All on the suite does delete the testuserdir. (It will not do so while the process is running, specifically when the lock file exists, as that can be dangerous.)
I don't know whether the problem is that the lock file exists (because the process was killed), or because on windows the dir can't be deleted (something or other has a file locked in it). Entirely possible that it's windows-specific, due to windows file locking issues or something. Try it on windows - if you really can't reproduce it there, then close.
Again, I can reproduce, but there's nothing to be done about it. Build | Stop Building fails to kill the subprocess; AFAIK stopping the Ant process will try to destroy() the subprocess but maybe it doesn't work in this case. You can kill the platform process using Task Manager but that does not remove the lock file, even though it is marked File.deleteOnExit; maybe a Java bug, maybe a Windows limitation. If you manually delete the lock file, then Clean on the suite does delete the testuserdir. Sorry, but until Java provides a way to both reliably and cleanly kill the subprocess, I don't see what we can do besides have a FAQ entry. It is unacceptable to delete a userdir with a lock file in it, even if there are no mandatory file locks, because you can inadvertently crash an otherwise fine process.
Can we at least have the clean task fail if it can't delete the test user dir? Then the user knows they have to do something; without it, weird things just happen.
Yeah, could do that.
Should halt the clean build now with a message in case the lock file is still there: committed * Up-To-Date 1.19 apisupport/harness/release/README committed * Up-To-Date 1.23 apisupport/harness/release/suite.xml committed * Up-To-Date 1.715 nbbuild/build.xml committed * Up-To-Date 1.21 nbbuild/templates/common.xml
Build fails with appropriate message. Verified.