"Source not found" for external dependencies when clicking on stack frame

Help/Discuss Buildship
1

In a pattern I can’t figure out, sometimes when I click on a debug stack frame for an external class, Eclipse finds the source for the class but sometimes I get a window with just the text “Source not found” and a “Edit Source Lookup Path…” button. In the latter case, I can do a standard Eclipse “Open Type” operation, supply the class name, and Eclipse is able to find the source file (from a source jar file in the Gradle cache directory tree). So it’s puzzling why the logic that follows my clicking on the stack frame can’t find it.

I don’t know if this is a Buildship issue (I’ve seen misbehavior of this sort in the past in non-Buildship Eclipse environments), but I figured I’d ask here anyway.

Also, sometimes when the source can’t be found the “Source not found” window contains the text:

The JAR of this class file belongs to container ‘Project and External Dependencies’ which does not allow modifications to source attachments on its entries

with no “Edit Source Lookup Path…” button, which is even more aggravating because I don’t have the option to click the button to sort things out.

I haven’t figured out the pattern for why sometimes I get one type of “Source not found” window and sometimes I get the other type of “Source not found” window.

Any clues?

Thanks.

Nat

2

Buildship by default tries to attach sources to all dependencies in the classpath container. If the source jar for a dependency is not available in the repositories then Buildship will silently continue only with the binaries. You can change the source download strategy and you can define custom source jar locations in the build script. Here’s how you do it:

apply plugin: 'java'
apply plugin: 'eclipse'

eclipse {
    downloadSources = true
    downloadJavadoc = false
    classpath {
        file {
            whenMerged { 
                def lib = entries.find { it.path.contains 'my-commercial-lib.jar' }
                lib.sourcePath = fileReference(file('libs/m-commercial-lib-source.jar'))
            }
        }
    }
}
3

In my case, the source jar file is available (under ~/.gradle).

I’m thinking now that the problem is caused by the fact that the run configuration (launcher) I’m using isn’t using what Eclipse calls the “default classpath” for the project specified by launcher. In particular, the launcher yields an actual classpath in the launched JVM that doesn’t include the external dependency that contains the class whose source file isn’t being found. (This all works because the launcher is launching Jetty, which is doing its own classloader munging.)

I’m guessing that when Eclipse looks for the source code for a class that’s referenced in a stack frame, it’s constraining itself just to the jars that are in the launcher’s classpath. This is as opposed to the Open Type command (which does find the source file), which presumably looks at all the jars in the workspace.

Does that sound plausible?

Unfortunately, I don’t think I can use the default classpath, because some of the external dependencies have classes that do static initialization and letting that happen before Jetty has sorted itself out will result in bad things happening.

So, in short I guess this isn’t a Buildship issue. Still, if anyone has any suggestions for workarounds, I’d be happy to hear them :slight_smile:

Nat

4

That does make a lot of sense. The type is probably coming from a different JAR (e.g. something that comes embedded with the launcher you are using) and that JAR has no source attachment. What launcher are you using specifically?

5

I’m using a regular Java Application launcher.

Anyway, I did some research (i.e., Googling) on this whole “source not found” topic and it’s definitely a popular topic and definitely not Buildship-specific. It happens whenever there’s a bunch of dynamic loading and classloader hackery going on (web app servers being a common case).

The solution that worked for me is the “sourcelookup” plug-in from the guy who’s the author of m2e (the Maven Eclipse plug-in which I’m familiar with from a previous job). I guess its creation was motivated by the need to debug the kind of dynamic loading scenarios that happen in Maven, and it has some m2e-specific stuff in it, but it falls back to just going to Maven Central for source jars so it works for me.