metHudson runs significant amount of code inside the Maven process for the native maven2 job type, and during the plugin development one would often like to debug this. Here's how you do it:
Hudson looks at the system property "hudson.maven.debugPort" and if this is set, every managed Maven process is launched with this port as the debugger port. Therefore, if you run
mvn -Dhudson.maven.debugPort=5001 hpi:run, then you can start a build normally from Hudson, then attach a debugger to port 5001 to see what's going on inside the managed Maven process.
Debug jobs selectively
The previous approach causes every job to launch with the debugger port, but you can also selectively enable the debugger support. This can be even used on the production system, and therefore very handy if you need to trouble-shoot a problem in a live system.
To do so, click "Advanced..." under the build section and add
"-Xdebug -Xrunjdwp:transport=dt_socket,server=y,address=5001" to the MAVEN_OPTS field. (And when you do this, there's no need to have the
hudson.maven.debugPort system property set. In this way, only builds of this job will be started with the debugger support.
Debug jobs on a slave
Debugging a maven job that runs on a slave works in a similar way. If port 5001 is already taken by Hudson's slave agent, then change the port to another value, e.g. 5002:
"-Xdebug -Xrunjdwp:transport=dt_socket,server=y,address=5002". Then connect your debugger to the IP address of your slave and the specified port (5001 or 5002).
CSET test - "Who Else Wants To 'Crack-The-Code' Of Your CSET Test In ONLY 7 Days And Go To $50,857.00 In California Teacher Salary Right Now...Much EASIER Than You Ever Thought Possible?"