Problem inspecting code with Advanced Source Lookup enabled (in a specific scenario) - Is this a bug?

[stephendnicholas]

Hi There,

I'm having an issue in Eclipse where I can't "Ctrl + I" to inspect code while debugging, with Advanced Source Lookup enabled. I believe this is related to m2e and might be considered a bug, but I'm not sure, so I wanted to ask here first. Any help/guidance would be appreciated.

The setup:

• A maven project in Eclipse
• This has some dependencies, but not the class I'm attempting to inspect
• The project itself makes use of org.eclipse.jetty code to start-up a server and has the class I'm attempting to inspect on the "extra classpath"
• I have a custom Eclipse plugin that programmatically creates an ILaunchConfiguration, and uses this to launch the maven project
• On this ILaunchConfiguration, I have specified a custom source path, which include an entry for the class I'm attempting to inspect

The symptom I'm seeing is that when I try to inspect the code, with Eclipse's Advanced Source Lookup enabled, I get an error dialog that states:

Unable to evaluate the selected expression:
To perform an evaluation, an expression must be compiled in the context of a Java project's build path. The current execution context is not associated with a Java project in the workspace.

Whereas with Advanced Source Lookup disabled, it works fine.

The reason I'm posting this here, is what I'm seeing in the flow of the code:

• The exception is being thrown from here: https://github.com/eclipse-jdt/eclipse.jdt.debug/blob/fbe88c82527a2bc54b34626e40a3c9410ba77a58/org.eclipse.jdt.debug.ui/ui/org/eclipse/jdt/internal/debug/ui/actions/EvaluateAction.java#L270
• And occurs because we are unable to translate the StackFrame into an IJavaProject via the call here: https://github.com/eclipse-jdt/eclipse.jdt.debug/blob/fbe88c82527a2bc54b34626e40a3c9410ba77a58/org.eclipse.jdt.debug.ui/ui/org/eclipse/jdt/internal/debug/ui/actions/EvaluateAction.java#L243
• Under the covers that call gets rooted to AdvancedSourceLookupDirector, and in turn to AdvancedSourceLookupParticipant
• Which ultimately ends up invoking registered instances of ISourceContainerResolver here: https://github.com/eclipse-jdt/eclipse.jdt.debug/blob/fbe88c82527a2bc54b34626e40a3c9410ba77a58/org.eclipse.jdt.launching/launching/org/eclipse/jdt/launching/sourcelookup/advanced/AdvancedSourceLookupParticipant.java#L143
• In my case one of these resolvers is org.eclipse.m2e.sourcelookup.internal.launch.MavenSourceContainerResolver, which returns an entry for the class I'm inspecting (hence the reason I've come to your door)
• This returns an instance of ExternalArchiveSourceContainer - See here:

  m2e-core/org.eclipse.m2e.sourcelookup/src/org/eclipse/m2e/sourcelookup/internal/launch/MavenSourceContainerResolver.java

  Line 60 in 112488c

  return new ExternalArchiveSourceContainer(sourceLocation.toString(), true);

• And this can't be adapted to a IJavaElement, which means the rest of the project location code doesn't resolve

When I disable the Advanced Source Lookup behaviour in Eclipse, AdvancedSourceLookupParticipant isn't in the picture, only JavaSourceLookupParticipant, which doesn't call through to m2e and so correctly refers to the source path I setup on the launch configuration.

I believe that if m2e wasn't returning an instance of ExternalArchiveSourceContainer at all, or was returning a different type of container that is adaptable to IJavaElement, then things would work.

So my question I guess is: Why is that type being returned by m2e? And is it a bug given the above observed behaviour?

A little digging suggests it has always been the case, since https://bugs.eclipse.org/bugs/show_bug.cgi?id=384065:

• b68b8b2#diff-21278cafee866700db7ff822759deed05aa7d453c857c5f78ad01f1cbb9c8a57

Hope that all makes sense, but please feel free to ask any clarifying questions

Steve