Community
Participate
Working Groups
Build Identifier: 1.0.0.20110607-2117 When a java project ran through maven, for i.e a web application ran with tomcat:run, neither project sources nor dependencies' sources cannot be located when a breakpoint hit. There were related tickets in the sonatype and codehous jiras. [1] [2] [1] https://issues.sonatype.org/browse/MNGECLIPSE-983 [2] http://jira.codehaus.org/browse/MECLIPSE-542 Reproducible: Always
Created attachment 201317 [details] Path to solve the issue
I'm also running into this when using the Jetty Maven Plugin and running "jetty:run". Eclipse will find the source code in existing projects but the only way to debug in the source for Maven dependency is to add the source jar manually. Selecting a "File System Directory" with "Search Subfolders" enabled will not work. Also, defining a a "Java Library" and adding all the source jars too it will not work.
You may want to try the m2e-wtp or Webby add-ons.
I have worked hard and provided the solution that I believe clean and neat. I am rather disappointed that there's no feed back on the issue. Regards, Hasan Ceylan
(In reply to comment #4) > I have worked hard and provided the solution that I believe clean and neat. > > I am rather disappointed that there's no feed back on the issue. > Sorry I did not make it clear, but the arguments against static calculation of source lookup path I outlined in [1] still fully apply. [1] https://issues.sonatype.org/browse/MNGECLIPSE-983?focusedCommentId=20261&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-20261
Excuse me if I sounded rather rude. I do not really get "static source lookup path won't work reliably" But as far as I can see for a single pom project there can be only one version of a particular dependence hence IMHO this should not be an issue. Could you create a test project to mimic your concern so I can test against my patched m2e? Regards,
Put a breakpoint anywhere in maven-compiler-plugin or tomcat:run or any other piece of code that is loaded dynamically either by maven or by the application being started. Or put a breakpoint somewhere in your code and click on different stack frames in debug view. Fundamentally, m2e does not have enough information to be able to calculate sources of dynamically loaded code upfront. When running project code through maven everything is loaded dynamically.
AFAIK, tomcat sources are not included in the maven repo. That might be why. I have been using self patched m2e for months and I can locate spring codes etc. Have your tries my patch on?
(In reply to comment #8) > AFAIK, tomcat sources are not included in the maven repo. That might be why. > I have been using self patched m2e for months and I can locate spring codes > etc. > > Have your tries my patch on? Fundamentally, Maven launch configuration launches Maven in external jvm. The only classes that will certainly be present on classpath of that jvm are maven core classes. Maven core will load and execute maven plugins and in some cases maven plugins will indeed execute code from the project. But this is really an exception, in most cases the code from the project will never run at all or will run in a separate process. Even if one of maven plugins does execute the code from the project, there is no way to tell if the plugin will use any of project dependencies or substituted them with something else. Proposed patch implements source path lookup behaviour appropriate when Maven launch configuration is used to execute tomcat:run with fork=false. For vast majority of other usages of Maven launch configuration, the patch either does not do anything useful or actually messes up source lookup path for maven core classes. Also, by design org.eclipse.m2e.launching does not have a dependency on m2e.jdt. Maven can build projects written in many different languages, so it should not be necessary to install jdt just to be able to launch Maven build from Eclipse. Also, although I am not 100% sure, I think JavaRuntime.resolveSourceLookupPat does not use Maven dependency resolution rules and dependencies will be wrong.
Igor, First of all thanks for taking time and telling me the insights of the issue. But what you say suggests that there is no way - without an addition to maven - to expose what artifact it uses at runtime. On the other hand this also implies the fact that the classes compiled by eclipse might be using different jars then potentially maven at run time picks. Since maven will not compile the classes if classes are already compiled by eclipse may result in odd behavior - which I think more critical then locating the right source jar at debug time. Further more, even though this might not be the best solution, the fact that a different jar could be picked by maven then eclipse is a very rare situation and at least in my case I have never had that issue although I fully appreciate your explanation. Bottom line is I think this is as is could be seen as "best effort" to locate sources and of tremendous help for those who love to debug through down in the base libraries. My humble idea is that therefore it does deserve to go through until a better solution comes along. Hope all this makes sense. Regards, Hasan Ceylan
No. At org.eclipse.m2e.launching level, the right solution is to implement JVMDI-based negotiation of actual runtime classpath between Eclipse and the target JVM. Hardcoding substandard support for one specific minority usecase is not appropriate. There are two changes to org.eclipse.m2e.launching that are acceptable and should solve your original problem 1. implement JVMDI-based negotiation of actual runtime classpath between Eclipse and the target JVM 2. provide API that would allow easy implementation of custom maven-based launch configuration (i.e. tomcat:run in your case) Both are generic enough to be part of m2e-core Maven launching support and I will be willing to review a patch that implements one or both of them.
I am not aware if it is possible to obtain classpath through JVMDI, therefore I'll have to stop there. However, IMHO, I believe the solution does help those developing java using maven and eclipse. In my organization now 20+ developers my patched version of m2e. On the other hand I do acknowledge that maven is not specific to java as a whole. Therefore you have the point to introducing JDT dependency is an issue. But correct me if I am wrong is there any eclipse distro that doesn't come with JDT? Or people use maven coding in different languages use eclipse and m2e, if so what is the percentage. I still think the solution might not be the best but helps %99.99. Decision is yours. I will continue to use patched version of m2e in my organization. Best Regards, Hasan Ceylan
I've introduced new mavenLaunchParticipants extension point and corresponding IMavenLaunchParticipant interface. This new extension point (hopefully) allows implementation of various source lookup approaches without need to make changes to m2e.launching bundle. To validate the new API I've implemented JDWP-based source lookup participant, you can read more about the approach here https://github.com/ifedorenko/m2e-extras/blob/master/README.md. It should be possible to implement the source lookup logic proposed in the comment #1 using the new API, but feel free to reopen this bugzilla if the new API does not support your usecase. *** This bug has been marked as a duplicate of bug 366998 ***
I have finally had time to get on top of this. Thanks for the guidelines. Regards, Hasan Ceylan
I guess we are missing IMavenLaunchDelegate interface.
(In reply to comment #15) > I guess we are missing IMavenLaunchDelegate interface. Can you elaborate?
Extension point attributes to an interface that does not exist: package org.eclipse.m2e.source.jdt; import org.eclipse.m2e.internal.launch.IMavenLaunchDelegate; public class MavenLaunchDelegate1 implements IMavenLaunchDelegate { public MavenLaunchDelegate1() { // TODO Auto-generated constructor stub } }
http://git.eclipse.org/c/m2e/m2e-core.git/commit/?id=2e80c6ad26170c79cca2b512566b12e974747b69
Moved to https://github.com/eclipse-m2e/m2e-core/issues/
