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

[Launching] automatically debug forked JVMs in Debug Maven build (#124) #471

Draft
wants to merge 5 commits into
base: master
Choose a base branch
from

Conversation

HannesWell
Copy link
Contributor

@HannesWell HannesWell commented Dec 29, 2021

This PR is the in progress work to resolve issue #124 whose goal is to automatically attach a remote Java application debugger to VMs forked from a Maven build process, which is for example used for surefire tests.

The work is not yet in good shape but it is a proof of concept that (should) works for the following plug-ins,:

  • org.apache.maven.plugins:maven-surefire-plugin
  • org.eclipse.tycho:tycho-surefire-plugin
  • org.eclipse.tycho.extras:tycho-eclipserun-plugin

What's working already:

  • If a Maven build is launched in debug mode and one of the plug-ins mentioned above is executed the corresponding debug properties are injected before the mojo is executed so that the forked VM waits for a listener to be attached. The ConsoleLineTracker detects that and automatically launches a Remote Java Application in debug mode.
    So if there is a break-point, for example in a test, the forked VM stops at that break point just like the VM was never forked.
    If the Maven build is launched in run mode it behaves as usual and does not modify the mojos that fork VMs.

What has to be improved:

  • Specification of the debug properties should be done via configuration files probably similar to the lifecycle-mapping metadata.
    • It should be possible for a plug-in to specify its debug-properties itself, maybe a connector should also be able to contribute debug properties (but this could be harder to implement because the connector lives in the Eclipse-VM while the DebugEventListener is in the Maven-Build-VM). M2E could ship the debug-properties for the most relevant plug-ins like maven-surefire. Tycho plug-ins could use the first way (at least for new releases). Another option would be to specify the debug-properties in the Eclipse preferences.
  • The task of the DebugLaunchParticipant is probably better placed in the calling code of the m2e.launching plug-in. Then it would not be necessary for the m2e.maven.runtime bundle to be a singleton so the extension-points are processed (even tough I wonder why M2E's Maven runtime components are not singletons.
  • Source look ups: At the moment the MavenConsoleLineTracker does not set the IJavaLaunchConfigurationConstants.ATTR_PROJECT_NAME of the launched remote Java application correctly when variables are used (which at least I usually do) so source are not available then. But I will address that in a separate PR where I want to rework the MavenConsoleLineTracker in general (it is almost complete).
  • Clean up

My main intention with this draft PR is to gather some early feedback, in general and especially about the definition of the debug-properties.
@laeubi you created the mentioned issue issued, @mickaelistria you might be interested too. What do you think?

Conflicts:
	org.eclipse.m2e.launching/src/org/eclipse/m2e/internal/launch/MavenConsoleLineTracker.java
	pom.xml
Conflicts:
	org.eclipse.m2e.core.ui.tests/src/org/eclipse/m2e/core/ui/tests/ConsoleTest.java
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

Successfully merging this pull request may close these issues.

3 participants