Ich dachte, ich würde diese Antworten für OSX- und Linux-Leute erweitern (nicht, dass sie es brauchen):
Ich bevorzuge auch mvnDebug . Aber nachdem OSX Maverick meine Java-Entwicklungsumgebung zerstört hat, fange ich bei Null an und stoppte diesen Beitrag und dachte, ich würde ihn ergänzen.
$ mvnDebug vertx:runMod
-bash: mvnDebug: command not found
DOH! Ich habe es nach dem neuen SSD-Laufwerk und / oder dem Zurücksetzen von Java bei der Installation von Maverick nicht auf dieser Box eingerichtet.
Ich benutze einen Paketmanager für OSX und Linux, daher habe ich keine Ahnung, wo mvn wirklich lebt. (Ich weiß es für kurze Zeit. Danke, Gebräu. Ich mag es, dass ich das nicht weiß.)
Mal sehen:
$ which mvn
/usr/local/bin/mvn
Da bist du ... du kleiner b @ stard.
Wo wurden Sie installiert, um:
$ ls -l /usr/local/bin/mvn
lrwxr-xr-x 1 root wheel 39 Oct 31 13:00 /
/usr/local/bin/mvn -> /usr/local/Cellar/maven30/3.0.5/bin/mvn
Aha! Sie wurden also in /usr/local/Cellar/maven30/3.0.5/bin/mvn installiert. Du freches kleines Bauwerkzeug. Kein Zweifel von Homebrew ...
Hast du deinen kleinen Kumpel mvnDebug dabei?
$ ls /usr/local/Cellar/maven30/3.0.5/bin/mvnDebug
/usr/local/Cellar/maven30/3.0.5/bin/mvnDebug
Gut. Gut. Sehr gut. Alles läuft wie geplant.
Bewegen Sie jetzt diesen kleinen b @ stard, wo ich mich leichter an ihn erinnern kann.
$ ln -s /usr/local/Cellar/maven30/3.0.5/bin/mvnDebug /usr/local/bin/mvnDebug
ln: /usr/local/bin/mvnDebug: Permission denied
Verdammt, du Computer ... Du wirst dich meinem Willen unterwerfen. Wissen Sie, wer ich bin? Ich bin SUDO! BOGEN!
$ sudo ln -s /usr/local/Cellar/maven30/3.0.5/bin/mvnDebug /usr/local/bin/mvnDebug
Jetzt kann ich es von Eclipse aus verwenden ( aber warum sollte ich das tun, wenn ich IntelliJ habe !!!! )
$ mvnDebug vertx:runMod
Preparing to Execute Maven in Debug Mode
Listening for transport dt_socket at address: 8000
Intern verwendet mvnDebug Folgendes:
MAVEN_DEBUG_OPTS="-Xdebug -Xnoagent -Djava.compiler=NONE \
-Xrunjdwp:transport=dt_socket,server=y,suspend=y,address=8000"
Sie können es also ändern (ich debugge normalerweise an Port 9090).
In diesem Blog wird erklärt, wie Sie das Eclipse-Remote-Debugging einrichten (Schauder).
http://javarevisited.blogspot.com/2011/02/how-to-setup-remote-debugging-in.html
Das Gleiche gilt für Netbeans
https://blogs.oracle.com/atishay/entry/use_netbeans_to_debug_a
Ditto IntelliJ
http://www.jetbrains.com/idea/webhelp/run-debug-configuration-remote.html
Hier sind einige gute Dokumente zum Befehl -Xdebug im Allgemeinen.
http://docs.oracle.com/cd/E13150_01/jrockit_jvm/jrockit/jrdocs/refman/optionX.html
"-Xdebug aktiviert Debugging-Funktionen in der JVM, die von der Java Virtual Machine Tools-Schnittstelle (JVMTI) verwendet werden. JVMTI ist eine Debugging-Schnittstelle auf niedriger Ebene, die von Debuggern und Profiling-Tools verwendet wird. Mit ihr können Sie den Status überprüfen und die Ausführung steuern von Anwendungen, die in der JVM ausgeführt werden. "
"Die von Profilern am häufigsten verwendete Teilmenge von JVMTI ist immer verfügbar. Die Funktionalität, die von Debuggern verwendet wird, um den Code zu durchlaufen und Haltepunkte festzulegen, ist jedoch mit einem gewissen Overhead verbunden und nicht immer verfügbar. Um diese Funktionalität zu aktivieren Sie müssen die Option -Xdebug verwenden. "
-Xrunjdwp:transport=dt_socket,server=y,suspend=n myApp
Schauen Sie sich auch die Dokumente auf -Xrunjdwp an. Sie können es nur aktivieren, wenn beispielsweise eine bestimmte Ausnahme ausgelöst wird. Sie können es ausgesetzt oder ausgeführt starten. Wie auch immer ... ich schweife ab.
ln -s /usr/share/maven/bin/mvnDebug /usr/bin/mvnDebug