Run & Debug outruns build

the app is run through maven, so the build is supposed to finish when the app finishes.
the stopping of the build is current very conservative and only stops when a single plugin execution finishes. if the plugin hangs, it cannot be stopped now..

can you attach a simple app that doens't work for you? does run open a new output tab?

Regretfully it is not problem of an application. At work I have simultaneously installed NB 5.0 and NB 6.0 M4. On NB 5.0 the same project runs & debugs ok on NB 6.0 M4 it hangs.

------------------------------------------
GOOD SCENARIO
------------------------------------------

The progress in NB 5.O is follow - i Hit F5 (and I have set breakpoint on first line of code):

1) new window appears with name fmc.prototypes:JavaMail:jar:1-0-SNAPSHOT
2) it displays following:

[INFO]JPDA Listening Starting...
[INFO]JPDA Address: novoj:44553
[INFO]Port=44553
[INFO]sourcepath=ClassPath[Entryfile:/home/novoj/Sources/Prototypes/JavaMail/src/main/java/, Entryfile:/home/novoj/Sources/Prototypes/JavaMail/src/test/java/]
[INFO]jdkSources=ClassPath[Entry[jar:file:/usr/lib/j2sdk1.6-sun/src.zip!/]]

3) then Debugger console appears with text (and other windows like local variables, watches and so):

Listening on 44553

4) meanwhile in window fmc.prototypes:JavaMail:jar:1-0-SNAPSHOT build continues:

[INFO]Scanning for projects...
[INFO]----------------------------------------------------------------------------
[INFO]Building JavaMail Prototype
[INFO] task-segment: [package, org.codehaus.mevenide:netbeans-run-plugin:LATEST:run-jar]
[INFO]----------------------------------------------------------------------------
project-execute
[INFO]artifact org.apache.maven.plugins:maven-resources-plugin: checking for updates from netbeansIDE-repo-internal
[INFO]artifact org.apache.maven.plugins:maven-compiler-plugin: checking for updates from netbeansIDE-repo-internal
[INFO]artifact org.apache.maven.plugins:maven-surefire-plugin: checking for updates from netbeansIDE-repo-internal
[INFO]artifact org.apache.maven.plugins:maven-jar-plugin: checking for updates from netbeansIDE-repo-internal
[INFO]artifact org.apache.maven.plugins:maven-assembly-plugin: checking for updates from netbeansIDE-repo-internal
[resources:resources]
[INFO]Using default encoding to copy filtered resources.
[compiler:compile]
Compiling 3 source files to /home/novoj/Sources/Prototypes/JavaMail/target/classes
[resources:testResources]
[INFO]Using default encoding to copy filtered resources.
[compiler:testCompile]
[INFO]No sources to compile
[surefire:test]
[INFO]No tests to run.
[jar:jar]
[INFO]Building jar: /home/novoj/Sources/Prototypes/JavaMail/target/JavaMail-1.0-SNAPSHOT.jar
[INFO]Preparing assembly:directory
[INFO]----------------------------------------------------------------------------
[INFO]Building JavaMail Prototype
[INFO]----------------------------------------------------------------------------
[WARN]Removing: directory from forked lifecycle, to prevent recursive invocation.
[resources:resources]
[INFO]Using default encoding to copy filtered resources.
[compiler:compile]
[INFO]Nothing to compile - all classes are up to date
[resources:testResources]
[INFO]Using default encoding to copy filtered resources.
[compiler:testCompile]
[INFO]No sources to compile
[surefire:test]
[INFO]No tests to run.
[jar:jar]
[WARN]DEPRECATED [descriptor]: Please use descriptors instead
[assembly:directory

]
[INFO]Copying 8 files to /home/novoj/Sources/Prototypes/JavaMail/target/executable-netbeans
[INFO]artifact org.apache.maven:maven-project: checking for updates from netbeansIDE-repo-internal
[INFO]artifact org.apache.maven:maven-project: checking for updates from mevenide
[INFO]artifact org.apache.maven:maven-plugin-api: checking for updates from netbeansIDE-repo-internal
[INFO]artifact org.apache.maven:maven-plugin-api: checking for updates from mevenide
[netbeans-run:run-jar]
[INFO]Executing "java -Xdebug -Djava.compiler=none -Xnoagent -Xrunjdwp:transport=dt_socket,server=n,address=49985 -jar JavaMail-1.0-SNAPSHOT.jar " in directory /home/novoj/Sources/Prototypes/JavaMail/target/executable-netbeans

5) then it stops on break point - in debugger console renders:

User program running
Breakpoint hit at line 67 in class fmc.prototypes.javamail.JavaMail by thread main.
Thread main stopped at JavaMail.java:67.

6) after finishing program ... build finishes in window fmc.prototypes:JavaMail:jar:1-0-SNAPSHOT with this text:

ans
[INFO]Exited with return code=0
[INFO]------------------------------------------------------------------------
[INFO]BUILD SUCCESSFUL
[INFO]------------------------------------------------------------------------
[INFO]Total time: 2 minutes 36 seconds
[INFO]Finished at: Thu Oct 26 08:23:42 CEST 2006
[INFO]Final Memory: 33M/66M
[INFO]------------------------------------------------------------------------

In debugger console renders:

User program running
User program finished

------------------------------------------
BAD SCENARIO
------------------------------------------

The progres in NB 6.0 M4 on the same project with breakpoint on first line of code is follow:

1) new window appears with name fmc.prototypes:JavaMail:jar:1-0-SNAPSHOT
2) it displays following:

[INFO]JPDA Listening Starting...
[INFO]JPDA Address: novoj:53947
[INFO]Port=53947
[INFO]sourcepath=ClassPath[Entryfile:/home/novoj/Sources/Prototypes/JavaMail/src/main/java/, Entryfile:/home/novoj/Sources/Prototypes/JavaMail/src/test/java/]
[INFO]jdkSources=ClassPath[Entry[jar:file:/usr/lib/j2sdk1.6-sun/src.zip!/]]

3) then Debugger console appears with text (and other windows like local variables, watches and so):

Listening on 44553

4) nothing else happens - build in window fmc.prototypes:JavaMail:jar:1-0-SNAPSHOT doesn't continue as it was in case of NB 5.0 - in right bottom corner progresbarr "Run Maven build" rotates, but never ends - I have to close whole NB to kill the thread

------------------------------------
CONCLUSION
------------------------------------

From my point of view there is no problem in project, but in NB version. Nevertheless, I'll pack my test project and enclose it to this bug. Thanks for you attention.

The project inside contains several bugs - so it probably won't run well. But it is no matter - the problem is in debugging this project.

I have put a breakpoint in the main method of class JavaMail and the debugger stopped there. if I let it run I get an error message (nb 60 trunk -post m4)

can you try creating a test ant j2se project with just a 2 or 3 lines in main() and try to debug it?so that we can eliminate the possibility that it's a problem of netbeans debugger in 6.0 m3 on your machine..

Yes, I can. But I fear that the problem is elsewhere.
I experienced similar behaviour while running simple "Run project". Suppose I have compiled all source files. Now I make some change (for example change in some configuration class) and then I hit F6 - Run Project. Mevenide starts build, then console is opened an program runs - but it runs with older version of class (the former one) - so the change is not taken into account. Then the build finishes.

When I run the same goal again my previous changes are in compilled classes, so when it runs I can see my changes. So it looks like, that run is executed before maven compile phase is finished. I'm nearly sure of it so I don't think that blaming NB 6 debbuger is the right way.

Can it be connected with performance of computer? I have AMD 64 3000+ on my system. I think that the problem is somewhere in synchronization of NB actions and Maven phases.

indeed. that was the the hint. it seems there is a bug in how the goals are ordered in the execution mappings. check your $

/nbactions.xml file.. it should have entries like this

<action>
<actionName>run</actionName>
<packagings>
<packaging>jar</packaging>
</packagings>
<goals>
<goal>package</goal>
<goal>org.codehaus.mevenide:netbeans-run-plugin:LATEST:run-jar</goal>
</goals>
<properties>
<netbeans.jar.run.params>xxx xxx</netbeans.jar.run.params>
</properties>
</action>

the goal "package" needs to be before the other goal, but sometimes isn't for some reason. I'll investigate and once I have a patch ready, I'll put it up on the update center.

a temporary workaround is to switch those goals in the nbactions.xml file

Yes, that`s it: I have there:

<goals>
<goal>org.codehaus.mevenide:netbeans-run-plugin:LATEST:run-jar</goal>
<goal>package</goal>
</goals>

I`ve corrected it in the nbactions.xml file and run is ok now. But the debug problem remains. It still hangs at:

[INFO]JPDA Listening Starting...
[INFO]JPDA Address: STAVAROV_89_8:3098
[INFO]Port=3098
[INFO]sourcepath=ClassPath[Entryfile:/C:/Sources/Fincom/Prototypes/JavaMail/src/main/java/, Entryfile:/C:/Sources/Fincom/Prototypes/JavaMail/src/test/java/]
[INFO]jdkSources=ClassPath[]

So I`ll try to test NB 6.0 debugger - according to your comment (http://jira.codehaus.org/browse/MEVENIDE-463#action_78748).

I have bad news. I`created a new NB project (based on ant) and simply put sources of my JavaMail project and necessary libraries. When I run debug (several breakpoints, multiple times) everything works okay. So we couldn`t blame NB debugger.

As I noticed when debugging in NB Ant project debugger is always on different socket (for example 4417, 4420, 4423 and so) - the sam does Mevenide debugger. But Mevenide debugger seems not to attach successfuly. Maybe it could help to extends some logging for Mevenide, in order to have more information? How can I do that?

for the first issue (wrong ordering of goals) i put up a hotfix on the update center. for already created nbactions.xml file, you will have to rever the ordering yourself manually though.

still investigating the second issue, not able to reproduce so far.

Can I do some research for you? Is there any way how to enable some logging or so? Or is there any way how could I debug it myself on my machine, where the error can be reproduced easily?

The problem seems to be in class JPDAStart on line 93:

92: getLog().debug("Entering wait");
93: lock.wait();
94: getLog().debug("Wait finished");

It runs into "lock.wait()" and never runs futher. It might be some deadlock issue? I don`t know yet - it`s not easy to debug debugger for me. I`ve never done this before .

After lock wait something writes following three lines into console:

[INFO]JPDA Address: STAVAROV_89_8:2084
[INFO]Port=2084
[INFO]sourcepath=ClassPath[Entryfile:/C:/Sources/Fincom/Prototypes/Java/JavaMail/src/main/java/, Entryfile:/C:/Sources/Fincom/Prototypes/Java/JavaMail/src/main/resources/, Entryfile:/C:/Sources/Fincom/Prototypes/Java/JavaMail/src/test/java/]
[INFO]jdkSources=ClassPath[]

I will look further. If you have any suggestions, I`ll appreciate them.

Further investigation reveals that it really hangs in JPDAStart on line 163:

JPDADebugger.startListening(
lc,
args,
new Object[]

);

It doesn`t finishes this command - so the finally clause won`t be interpreted - there is lock.notify(); which disposes the lock as I mentioned in previous comment. I wonder why the startListening doesn`t pass. Unfortunately this is inside Netbeans. Any suggestions?

I've checked the netbeans ant task and that one seems to the approximately the same but calls the startListening method asynchronously. I wonder when the semantics changed, Could be worth a try (enclose the JPDADebugger.startListening method into

// Let it start asynchronously so that the script can go on and start the debuggee
RequestProcessor.getDefault().post(new Runnable() {
public void run() {
try {
JPDADebugger.startListening (
flc,
args,
new Object[]

);
} catch (DebuggerStartException dsex)

}
});

on another note.. do you have any restrictive firewall that could prohibit opening a port on the machine?

1) I disabled all my guard dogs - firewall, antivirus and others and I can confirm, that this wasn`t my problem. Debug hung as it did before.

2) I tried your suggestion and .... it worked. After building NBM and update module in my NB 6.0 I tried to debug my application 10 times, and it stopped at breakpoint at each try. So I can confirm your correction.

ok, commited to trunk and the 2.3 release as well.. I think it deserves to be put on the update center

uploaded new version of modules to the update center with this fix.