Community
Participate
Working Groups
Created attachment 264059 [details] patch that makes MavenRuntimeClasspathProvider open for all launch configuration types In MavenRuntimeClasspathProvider the method getArtifactScope() determines whether the classpath should contain the RUNTIME scope or the TEST scope. The default is RUNTIME. The scope TEST is used for test execution or execution of a class in the test directory. So far so good. The method also checks the launch configuration type and throws an Exception if the type is not known. I do not understand why this is necessary, because returning a reasonable default, i.e. RUNTIME scope, would make the class more versatile. Actually I do have a workaround solution (Eclipse fragment of m2e) for a custom Jetty plugin doing exactly this (RUNTIME scope instead of Exception). The soulution works very well for debugging web applications with Maven dependencies in the workspace. Neither Eclipse Jetty Integration nor Run Jetty Run can do this. If MavenRuntimeClasspathProvider could return the RUNTIME scope instead of throwing an Exception, then I could get rid of the Eclipse fragment workaround. Maybe other projects could benefit from that change as well. I also have a patch ready. Please have a look into the attachments.
There is no meaningful default scope. You need to extend MavenRuntimeClasspathProvider and override getArtifactScope to support your specific launch configuration type.
Igor, thanks for your quick reply! 1. I have a custom Jetty plugin. It runs a web application for debugging purposes. The project could be a classic Eclipse project, a Maven project, a Gradle project, or any other kind of project. I think, it does not need to know (explicitly) which kind of project it runs, neither do special handling for single project types, nor have dependencies on m2e or other, unless it is absolutely necessary. 2. When I extend MavenRuntimeClasspathProvider, then I get warnings about discouraged access of internal (not public) API. This is not best practice and I would do only if absolutely necessary. 3. I still think, that the RUNTIME scope is a good default. It may not cover all cases, but at least it would cover the cases needing RUNTIME scope. Then everything worked perfectly without the need of extending MavenRuntimeClasspathProvider. When TEST scope is needed, then one needs to depend on m2e and extend MavenRuntimeClasspathProvider anyway. I think everybody would win when the RUNTIME scope is returned as default instead of throwing an Exception.
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.
Moved to https://github.com/eclipse-m2e/m2e-core/issues/
