Community
Participate
Working Groups
Created attachment 267692 [details] eclipse.jdt.debug.patch - The patch The Problem ----------- The problem occurs when debugging a Maven web application with Eclipse Jetty Integration plugin. Then the sources of Maven dependencies that are open projects in the Eclipse workspace cannot be found. The problem also occurs for my own custom launch configuration; basically any launch configuration other than Java, JUnit or TestNG. Reproducibility --------------- The attached projects.zip contains 4 projects: twice a web application project and a dependency; one time as standard Eclipse projects and another time as Maven projects. One can import the projects into an Eclipse workspace, define a break point in the "Dep" classes in the eclipse-dep and maven-dep projects, launch the given Eclipse Jetty Integration launch configurations with "Debug As" and load http://localhost:8080 with a browser of choice. The standard Eclipse project properly halts in Dep.java, showing the source code. The Maven project does not find the source code of Dep.java. Maven Source Lookup ------------------- The Maven Source Lookup does work for Java launch configurations, JUnit and TestNG tests. This works because m2e hooks into launch configuration creation and adds CLASSPATH_PROVIDER and SOURCE_PATH_PROVIDER to these types of launch configurations. It would be nice if this worked for any launch configuration, or at least when added manually. I reported that as a bug already (https://bugs.eclipse.org/bugs/show_bug.cgi?id=501099) but there is no progress there. Anyway, since I think, neither m2e should know about Jetty, nor Eclipse Jetty Integration whether it is a Maven project, the problem should be solved here. The Bug ------- The bug is located in StandardSourcePathProvider. The Maven container (MavenClasspathContainer) is resolved with JavaRuntime.resolveRuntimeClasspathEntry(...), which produces a runtime classpath (output locations) instead of a source lookup path (project references). The Patch --------- Attached you can find a patch for the problem: eclipse.jdt.debug.patch The patch adds methods resolveSourceLookupClasspathEntry(...) to JavaRuntime and changes the calls in StandardSourcePathProvider. I had different ideas for the patch. I finally decided for that one, because it does a lot of copy&paste, which makes it sort of obvious what is going on: do twice the same with some small differences. The other solutions were not elegant either. Finally, this was the only way not breaking the contract of JavaRuntime.resolveRuntimeClasspathEntry(...): * ... If the entry is of kind <code>PROJECT</code>, * and the associated Java project specifies non-default output locations, * the corresponding output locations are returned. Otherwise, the given * entry is returned. I found it quite confusing, that some projects get expanded to the output locations here and others have to be expanded later (in AbstractJavaLaunchConfigurationDelegate). Maybe it would be a good idea to refactor JavaRuntime, but that is a different story. We can talk about this, if somebody is interested.
Created attachment 267693 [details] The projects to reproduce the problem
Claus, thanks for the report and patch. Can you please create a gerrit change with your patch? See https://projects.eclipse.org/projects/eclipse.jdt.debug/developer.
Also, can you specify the plugins which should be installed to test this on Eclipse SDK ?
Sarika, you'll need m2e and Eclipse Jetty Integration plugins for testing this bug. m2e should already be included in Eclipse SDK. *Expert Mode:* You do not even need the Eclipse Jetty Integration plugin. The *-war projects contain a "launch" directory with prepared launch configurations. Since the example servlets also contain a main method, there are standard Java launch configurations. maven-war-java.launch contains the CLASSPATH_PROVIDER and SOURCE_PATH_PROVIDER (added by m2e) as stated in the bug description. The source lookup will work. maven-war-java-without-classpath-provider.launch does not contain these providers. I removed them. Therefore the same StandardSourcePathProvider will be used as with the Eclipse Jetty Integration launch configuration. The source lookup will fail. Unfortunately, when importing the projects into Eclipse, the CLASSPATH_PROVIDER and SOURCE_PATH_PROVIDER are added to the maven-war-java-without-classpath-provider.launch. You will have to remove them again after the import. Sorry for that. I wish it would be different. Hence, expert mode. But if you do this way, you can spare the Eclipse Jetty Integration plugin and the browser for testing. This is much quicker.
New Gerrit change created: https://git.eclipse.org/r/94702
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. As such, we're closing this bug. If you have further information on the current state of the bug, please add it and reopen this bug. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. -- The automated Eclipse Genie.
Gerrit is pending review, if someone can help!
I'd like to vote for this topic as well. We are using eclipse with git/maven for software development in our company and are facing major issues when debugging applications. Imagine working on the next version of an application while having to maintain a couple of previous releases. In this scenario, we are switching between tags/branches back and forth using the same eclipse workspace (that's where git-integration really shines). When debugging an application up to its dependencies (we have the sources for these), developers are forced to specify the matching source archives in their launch configurations manually. Now, switching to another tag/branch requires the launch configurations to be adjusted. When having a great number of dependencies, this becomes really cumbersome and error prone. Failing to adjust the launch configuration results in the binaries not matching the specified source code (although the source code fetched from the maven repository is correct), thus confusing developers even further. The feature introduced with this topic would greatly increase productivity and improve debugging. Is there any chance to include it in the next eclipse release?
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. -- The automated Eclipse Genie.
