Created attachment 110087 [details]
stacktrace

When you close the IDE and try to open created project, it works.

Probably only affects the first such project creation. But I am unable to reproduce the problem, even with an empty local repo. Probably related to FoD?

I can report it better from the Maven side (core-main #c8d93c4c8129), but the real problem is in the module system: a ThreadDeath thrown in the middle of class loading (seems like you somehow interrupted archetype creation?) is interpreted as a missing resource, which is then cached. Rather, the whole loading thread should just be stopped.

Were you able to consistently reproduce somehow? If so, let me know if the attempted fix worked, else attach new logs.

core-main #269a8ceaa338

Integrated into 'main-golden'
Changeset: http://hg.netbeans.org/main-golden/rev/c8d93c4c8129
User: Jesse Glick <jglick@netbeans.org>
Log: Better handling of #201098: if the embedder is broken, just throw ISE, do not quietly return null.

I am still able to reproduce the problem with steps in original description. It means FoD is in action when I click Next in the wizard. I don't interact anyhow with the IDE after I click the Finish button.

Product Version: NetBeans IDE Dev (Build 201108210601)
Java: 1.7.0; Java HotSpot(TM) Client VM 21.0-b17
System: Windows XP version 5.1 running on x86; Cp1250; en_US (nb)

Created attachment 110124 [details]
New stack traces.

core-main #44c5d94dacde

Integrated into 'main-golden', will be available in build *201108230601* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)
Changeset: http://hg.netbeans.org/main/rev/44c5d94dacde
User: Jesse Glick <jglick@netbeans.org>
Log: #201098: NullPointerException at org.netbeans.modules.maven.api.NbMavenProject$1.run

Created attachment 110175 [details]
New stack traces.

Still throwing an exception. Please, look at new stack traces.

I cannot reproduce it even after building ide.ergonomics. But from the new stack trace it looks like there is another problem in RequestProcessor, besides the one I fixed in the module system.

core-main #7fb5ef1cea79

Integrated into 'main-golden'
Changeset: http://hg.netbeans.org/main-golden/rev/7fb5ef1cea79
User: Jesse Glick <jglick@netbeans.org>
Log: #201098: ThreadDeath mishandled in platform

Created attachment 110212 [details]
New stack traces.

I see RequestProcessor changed to:

jglick: } catch (ThreadDeath t) {
jglick:   // #201098: ignore
jglick: }

where the ThreadDeath exception ends. What else should be done? Passing to maven. Btw. I used following code to emit the error:

diff -r ac91c811bd21 maven/src/org/netbeans/modules/maven/newproject/ArchetypeWizardUtils.java
--- a/maven/src/org/netbeans/modules/maven/newproject/ArchetypeWizardUtils.java Thu Aug 25 10:36:54 2011 +0200
+++ b/maven/src/org/netbeans/modules/maven/newproject/ArchetypeWizardUtils.java Fri Aug 26 10:46:36 2011 +0200
@@ -243,6 +243,7 @@
         System.setProperty(USER_DIR_PROP, directory.getAbsolutePath()); //NOI18N
         try {
             ExecutorTask task = RunUtils.executeMaven(config); //NOI18N
+            if (true) throw new ThreadDeath();
             task.result();
         } finally {
             if (oldUserdir == null) {

So what is wrong with maven? Is something misconfigured on my computer? If I run IDE from latest sources (#caeb55595ac2), it doesn't open created maven project and logs ThreadDeath from org.codehaus.plexus:

Caused: org.codehaus.plexus.component.repository.exception.ComponentLookupException: java.lang.ThreadDeath
      role: org.apache.maven.Maven
  roleHint: 
	at org.codehaus.plexus.DefaultPlexusContainer.lookup(DefaultPlexusContainer.java:247)

If I revert changeset #ec4cd73c9c75 back to parent #191de0faaf64, it opens created maven project but prints a lot exceptions to the log and ends with the same ThreadDeath.

$ hg revert -r 191de0faaf64 maven.apisupport maven.embedder maven.j2ee maven.
profiler maven

With NetBeans 7.0.1 it works without problems and without exceptions.

Created attachment 110244 [details]
Latest sources log (#caeb55595ac2).

Created attachment 110245 [details]
Reverted sources log (#191de0faaf64).

Downgrading; I cannot reproduce using a natural workflow (will try trick in comment #16). It likely only affects ergonomics builds anyway; if so, workaround is simply to make sure Java feature (or in this case EE feature) is enabled before trying to use it. But your comment about ec4cd73c9c75 makes me wonder whether you just did not do a clean build. At any rate, I have no idea what would be killing the thread to begin with.

Stack traces from comment #15 still show a problem with RequestProcessor (as mentioned in comment #16). One of your logs shows a possible problem with TD being wrapped in a ComponentLookupException.

P2 again: Another user tried it on his computer with Windows7 and he is able to reproduce it the same way (see messages-ergonomics-windows7.log). It means it can be blocker for users who install IDE from scratch and want to use maven web projects.

It is reproducible with (messages-ergonomics.log) or without ergonomics cluster. But without ergonomics it sometimes throws exceptions to window (messages-no-ergonomics.log) and sometimes project is successfully opened but exceptions are still printed to log file (messages-no-ergonomics-success.log).

I am able to reproduce it with local build from repository or with official zipped distribution.

Created attachment 110263 [details]
Log files.

I could reproduce the New Project wizard hang on XP with an initially empty local repo, but not any other exception. Could close the wizard dialog manually but something was still stuck; closing the IDE main window did not stop the process; but the thread dump (Ctrl-Break) showed nothing waiting so I am not sure how to diagnose.

On Windows the ExecutorTask appears to finish some time after the external process finishes, for unknown reasons. The problem is that DefaultSysProcess.stop calls ThreadGroup.stop() to prevent a memory leak, in case >3000msec have elapsed and the process does not seem to have finished. I seem to have a fix which avoids TG.stop but still releases references under normal circumstances, which may be safer.

Bug #197727 may be related (but probably not).

Inserting Thread.currentThread().stop() into ArchetypeWizardUtils does not reproduce anything for me on Linux - the wizard stops processing but Maven works fine after that. That is probably the wrong thread to stop anyway - the stack traces show ThreadDeath as if it were thrown from the thread calling Thread.stop, rather than the actual target thread - but adding this call to the start or end of MavenCommandLineExecutor.run does not reproduce anything either. The real bug is happening when a thread somewhere in the middle of creating a MavenEmbedder is killed.

A fix of #191951 would remove the bug trigger if it no longer called ExecutorTask.stop(), but I have not found a sufficiently safe fix along those lines yet.

I opened https://github.com/sonatype/sisu/pull/2 for Sisu (used in Maven); I think I can work around it in the NetBeans embedder.

core-main #1c97d5776d7a

The fix verified in build 201109040600. Thanks.