Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Auto attach Eclipse debugger to Surefire process when running "Debug as -> Maven test" / Improve M2E Run As Menu Options #124

Open
laeubi opened this issue Mar 30, 2021 · 4 comments
Assignees

Comments

@laeubi
Copy link
Member

laeubi commented Mar 30, 2021

See https://bugs.eclipse.org/bugs/show_bug.cgi?id=428792 for previous discussions.

I think this feature would be of great value as of today its very inconvenient to debug maven tests. To reduce confusion I think we should remove all this stuff from Debug > ... menu completely, I have literally never found it useful (anyone really debugging a mvn clean session here?) in any way and its always ends in "Debug As > ... ".... WTF??--- Damn need Remote debugging ... struggling around how to enable it... finally getting mad and fire up a shell to call mvnDebug, then struggling around to create a new remote debug config for the given project (have I really checked all dependent source projects ....??)

So to make this really useful "Debug As" should only provide these items:

  1. "maven build" ... (that open the usual dialog and provides 'old' behavior)
  2. "maven test" what do the following:
    1. chooses a free random port to use for remote debugging
    1. configures maven as mvnDebug does to debug tests
    1. creates a temporary remote debugger that waits for maven process, attach automatically and configures the source lookups according to current m2e settings (e.g. respecting 'resolve workspace artifacts or not)
    1. if the run finishes it even should fire up a Junit view showing failed/successful tests allowing to run/debug individual test.
  1. "maven test ... " that opens a run configuration editor to tune this more (e.g. configure -X or whatever)
@laeubi
Copy link
Member Author

laeubi commented Mar 30, 2021

@laeubi laeubi changed the title Auto attach Eclipse debugger to Surefire process when running "Debug as -> Maven test" Auto attach Eclipse debugger to Surefire process when running "Debug as -> Maven test" / Improve M2E Run As Menu Options Mar 30, 2021
@HannesWell
Copy link
Contributor

Providing a one-click solution to debug tests that run during a Maven build would be great feature that I would really appreciate.

The first time I wanted to debug tests executed during build i first had to learn the difference between between launching a Maven-build as debug as (were you debug Maven itself), debugging Tests executed by Maven-Surefire and debugging tests executed by Tycho-Surefire (using the DebugPort and a remote debugger launched from my eclipse). At that time I was not yet very familiar with the whole Maven-Build/Tycho topic and it took some time and multiple attempts to learn the difference and make it work.

To simplify debugging of tests and to avoid the same pain for my colleges have written a little plugin for my company that is installed in our development-Eclipses and adds a button that does the following

  • launch the selected Maven-Build launch-config (in Run-mode) and add the debugPort argument using a free port as value (we only have Eclipse builds using tycho, so Maven-Surefire is not of concern).
  • Adds a ConsoleLineTracker similar to the org.eclipse.m2e.internal.launch.MavenConsoleLineTracker. In contrast to the MavenConsoleLineTracker that line tracker launches the remote application immediately. I have to admit I never understand the use of creating a link because you can either click it to launch the debug-application or (and I can see no alternative) you can terminate the build.

So to achieve seamless debugging of tests executed in builds, adjusting the MavenConsoleLineTracker and passing the corresponding command-line properties could be sufficient.

What could also be possible, is to extend/add a Launch participant for Maven-Launches that adds a debugPort (for Tycho-Surefire) respectively a maven.surefire.debug (for Maven-Surefire) property and a corresponding argument using a free port as value, if the Launch-Mode is debug. So everything could be debugged (Maven itself, Maven-Surefire and Tycho-Surefire tests) at the same time. I've tried this a while ago and there were some interference so this did not work, but I can try it again and have a deeper look at it.

I also want to remark that currently the options displayed in the Run/Debug as sub-menue for a Maven project like Maven build, Maven clean, Maven install and Maven test just setup different last lifecycle phases. If now the Debug as menu provides a option maven test that actually runs the Maven build and only debugs the tests, this would be an inconsistent behavior.

Additionally it would be great if the debug functionality of tests would also be available for pre-configured launch configs. When I right click on such launch-config I can only select Run as or Debug As without any further options. We have an Eclipse based product that is build pom-less with tycho and I would like to avoid importing the root of the repo (where the pom.xml is located) into the workspace, just to make the Debug options available.

If nobody is working on this already I can offer to do it in the near future.

@laeubi
Copy link
Member Author

laeubi commented May 16, 2022

@HannesWell I think you have already done some things here, do you think we can mark this as fixed and maybe open more dedicated issues?

@HannesWell
Copy link
Contributor

@HannesWell I think you have already done some things here, do you think we can mark this as fixed and maybe open more dedicated issues?

It has been improved yes, but I think #471 should be completed to resolve this one (it is dedicated to this issue).
Furthermore we should also support polyglot projects like Eclipse-Plugin projects that don't have an explicit pom, which is addressed in #572 but that has to be reworked.

So I think this should stay open.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants