search

eclipse-m2e / m2e-core

Eclipse Public License 2.0
113 stars 115 forks source link

Eclipse 2022-12 won't auto attach debugger with External maven installations #1179

Open CarlosMOGoncalves opened 1 year ago

CarlosMOGoncalves commented 1 year ago

Description

Hello there,

I just found out an issue regarding auto-attachment of the debugger to certain applications initiated by a Maven Debug Configuration. This started on the latest version of Eclipse IDE for Enterprise Java and Web Developers 2022-12.

In short, since Eclipse 2022-03 (I think), whenever I booted an application from the Maven Debug Configurations Eclipse would auto-attach the debugger to it, which avoided the work of having to create a Remote Java Application configuration that would attach to the debug port (this was a lifesaver).

Now on Eclipse 2022-12 that not longer works whenever that Maven Debug Configuration uses any other Maven installation other than the one bundled with Eclipse itself. It will still work as expected using the bundled one.

Expected Outcome

I expect the debugger to be automatically attached to the application I want to debug without having to create a Remote Java Application Configuration and using whichever installation of Maven I want, just as it was on the previous Eclipse version.

Current Outcome

Currently, when I start an application with the Maven Debug Configuration it will:

  1. If I use any Maven installation from my environment it will start listening to the debug port (5005 in this case) and stop waiting for any Configuration to attach to that port and proceed with boot
  2. If I use the EMBEDDED Maven installation it will start listening to the debug port BUT will automatically attach the debugger to the port and proceed with boot

Steps to reproduce

I have prepared a sample application that has a very simple Payara Micro application It can be found here

This app does nothing special. It has a Jakarta REST endpoint but that is just for show.

  1. Fresh install Eclipse for Eclipse IDE for Enterprise Java and Web Developers 2022-12
  2. Checkout the project from my repository
  3. Proceed to build the project using mvn clean install
  4. This will create a JAR application on the /target folder that can be booted with a maven plugin command
  5. Create a Maven Debug Configuration as seen below

image

6.This configuration will trigger a plugin called payara-micro-maven-plugin that is configured in the POM to start in debug mode, hence the debug profile. This can be inspected in the pom.xml. 7.Create a directory in the OS where different maven binaries reside, like the one below: image

  1. Then just try to run that Debug configuration with either the EMBEDDED Maven and with any of the external installations.

image

  1. When using the EMBEDDED the app will start and auto attach the debugger like such:

image

11.When using any of the EXTERNAL Maven binaries it will be stuck waiting for a debugger connection:

image

12.The very same steps can be done with Eclipse 2022-09, where any maven distribution will work just fine.

Final note

Environment

HannesWell commented 1 year ago

In short, since Eclipse 2022-03 (I think), whenever I booted an application from the Maven Debug Configurations Eclipse would auto-attach the debugger to it, which avoided the work of having to create a Remote Java Application configuration that would attach to the debug port (this was a lifesaver).

Glad you like it.

The issue you described is (very likely) caused by https://github.com/eclipse-m2e/m2e-core/pull/572, which enhanced the auto-attachment of debuggers to work with polyglot projects too. But this requires an extra class in the maven-installation that is not available in external maven installations. Is there a specific reason why you cannot use the embedded one? In your screenshots I see you have Maven 3.8.7. The latest m2e-snapshots has that version already embedded (we usually try to updated as soon as possible): https://download.eclipse.org/technology/m2e/snapshots/2.2.0/

If you really need to use a external version, you could consider to add a jar (or maybe even a folder-structure works) to the lib/ext folder of your external installation, that contains the org.eclipse.m2e.internal.maven.listener.M2EMavenBuildDataBridge.java. The META-INF/sisu/javax.inject.Named file is probably also necessary. You can find both in the org.eclipse.m2e.maven.runtime jar of your Eclipse installation with M2E.

If there is a great demand for that we could even consider to provide such jar by default, but that would require some changes within M2E and I think that is currently worth the effort.

CarlosMOGoncalves commented 1 year ago

Glad you like it.

Yes, this was really great! The amount of time and work it saved me was massive. Thanks a lot for this feature!

Regarding the rest: No, the truth is I don't really need an External version. The reason I had it was because some months ago I needed to test a new feature that was present in the absolute latest maven version and from that point on I took the habit of having my own external install. However, I do update Eclipse very regularly, so if you keep updating it this fast it won't be a problem for me.

I was a bit worried because I had just updated Eclipse and this stopped working immeadiately and since this was a great time saver for me I decided to open this issue. But while I was testing it for this ticket, I verified it still worked with the Embedded version, so it is still fine by me. Nevertheless it might make sense to have a look at this in the future because it might make sense for some other users and using an external maven version is still a valid use case.

Thanks a lot for your quick answer. You may close this as your discretion.

laeubi commented 1 year ago

@HannesWell I'm not checked this, but if we run an "external" maven I think we still setup the classpath, so it might be possible to just put the m2e-supplement jar on the maven classpath as well...