Update on the current status of this bug. Maven launch configuration source lookup was reworked to use sources of the actual maven runtime being launched.
Source lookup is still broken for code that is dynamically loaded by Maven at runtime (i.e. Maven plugins). Current plan is to use JVMDI to query target JVM about artifacts used at runtime.
Alternative solution is to calculate source lookup path based on plugin configuration from project pom.xml. This approach has number of disadvantages, however.
First, static source lookup path won't work reliably when multiple versions of the same plugin or plugin dependencies are involved in the build.
Second, m2e will have to resolve/download all source jars in advance, before launching the build. This can probably be remediated by GUI that shows all build runtime dependencies, however.
And last, but not the least, calculating proper build runtime classpath is either very difficult or impossible. Versions of many commonly used plugins come from super-pom of the target maven runtime (we can theoretically read that). Then there is code in maven core that "filters" plugin dependencies (we'd actually have to run that code to know what's filtered). Then we have all regular inheritance, profiles and interpolation issues, which likely behaves slightly differently on different versions of maven. And we'll likely have to consider specific of the target JVM to deal with profiles activated based on system properties, for example.
Based on this, JVMDI-based approach provides better functionality and should actually be easier to implement. As far as I know, PDE already uses JVMDI during bundle source code lookup, so we should be able to use the same JDT debugging support in m2e.