Bug 216841

The build succeeded on my computer:

com.mercur.help.nbm:
Building jar: /home/jarda/tmp/TestSuite/build/updates/com-mercur-help.nbm
Not signing NBM file /home/jarda/tmp/TestSuite/build/updates/com-mercur-help.nbm; no stored-key password provided or keystore (/home/jarda/tmp/TestSuite/Oracle Help/${keystore}) doesn't exist
Creating update description /home/jarda/tmp/TestSuite/build/updates/updates.xml
Creating group "null"
Creating group "Help"
 Adding module Oracle Help (/home/jarda/tmp/TestSuite/build/updates/com-mercur-help.nbm)
BUILD SUCCESSFUL (total time: 34 seconds)


Try to generate stacktrace of the Ant process (Ctrl+\ on Unix or using jvisualvm), so we know what the build is waiting for in your case.

I am able to reproduce the problem too.

It is "pack200" that is hanging with stack:

"main" prio=5 tid=0x00007f8f79803800 nid=0x10bea1000 runnable [0x000000010bea0000]
   java.lang.Thread.State: RUNNABLE
	at java.io.FileOutputStream.writeBytes(Native Method)
	at java.io.FileOutputStream.write(FileOutputStream.java:318)
	at java.io.BufferedOutputStream.write(BufferedOutputStream.java:122)
	- locked <0x00000007df6039e0> (a java.io.BufferedOutputStream)
	at java.io.PrintStream.write(PrintStream.java:480)
	- locked <0x00000007df6039c0> (a java.io.PrintStream)
	at sun.nio.cs.StreamEncoder.writeBytes(StreamEncoder.java:221)
	at sun.nio.cs.StreamEncoder.implFlushBuffer(StreamEncoder.java:291)
	at sun.nio.cs.StreamEncoder.flushBuffer(StreamEncoder.java:104)
	- locked <0x00000007df603b10> (a java.io.OutputStreamWriter)
	at java.io.OutputStreamWriter.flushBuffer(OutputStreamWriter.java:185)
	at java.io.PrintStream.write(PrintStream.java:527)
	- locked <0x00000007df6039c0> (a java.io.PrintStream)
	at java.io.PrintStream.print(PrintStream.java:669)
	at sun.util.logging.PlatformLogger$LoggerProxy.doLog(PlatformLogger.java:365)
	at sun.util.logging.PlatformLogger.warning(PlatformLogger.java:235)
	at com.sun.java.util.jar.pack.Utils$Pack200Logger.warning(Utils.java:194)
	at com.sun.java.util.jar.pack.Utils$Pack200Logger.warning(Utils.java:198)
	at com.sun.java.util.jar.pack.PackerImpl$DoPack.readClass(PackerImpl.java:519)
	at com.sun.java.util.jar.pack.PackerImpl$DoPack.run(PackerImpl.java:485)
	at com.sun.java.util.jar.pack.PackerImpl.pack(PackerImpl.java:99)
	at com.sun.java.util.jar.pack.Driver.main(Driver.java:311)

I also took a heap dump, and dug around some in that. It is attempting to write to System.err and what it is trying to write is:

aug 21, 2012 12:47:26 EM com.sun.java.util.jar.pack.Utils$Pack200Logger warning\u000aWARNING: Passing class file uncompressed due to unrecognized attribute: ice/mozilla/javascript/ClassNameHelper.class\u000a

It turns out that Java version matters. It works fine with Java 6 but hangs with Java 7 (at least in Netbeans 7.1.2).

As pack200 is also java process, it may make sense to generate its stacktrace with jstack and report bug to JDK.

The MakeNBM ant task doesn't read the stdout or stderr of the child pack200 processes. If pack200 generates too much output, it will hang because the output buffers are full. 

The MakeNBM ant task launches pack200 using ProcessBuilder/Process. It starts the pack200 and then immediately waits for it to complete like so (NB 7.3.1 code snippet of org.netbeans.nbbuild.MakeNBM):
                Process process = pb.start();
                result = process.waitFor();

If pack200 generates too much output to either of these streams, it will block until the parent process reads stdout or stderr to create more room in the output buffers. But as you can see from that code, the parent process is blocked waiting for the child to complete. 

This is why the NBM ant target can hang. Normally, pack200 doesn't generate a lot of output, but some jar files can cause it to generate a lot of warnings. I experienced this in NetBeans 7.3.1 using JDK 7u72 with a module that wrapped a spring framework jar. Pack200  generates multiple warnings with the text "WARNING: Passing class file uncompressed due to unrecognized attribute".

Killing the pack200 process will let the NBM task continue, but I don't know if the resulting NBM is valid.