Support dependency sources from a directory, not a JAR

[dccorona]

I am trying to integrate bloop support for a build system that supports a non-Maven package manager, which fetches sources as a directory rather than a sources JAR. It would be great if bloop could support directories in the resolution array, like so:

{
  "project": {
    "resolution": {
      "modules": [
        {
          "organization": "org",
          "name": "name",
          "version": "ver",
          "configurations": "default",
          "artifacts": [
            {
              "name": "name",
              "classifier": "sources",
              "path": "/path/to/sources/dir"
            }
          ]
        }
      ]
    }
  }
}

I did try quickly adding this support by modifying frontend/src/main/scala/bloop/dap/BloopDebuggee.scala, but it seems that just changing that file is not enough on its own. I will keep trying, but wanted to file the issue in case anyone else has any thoughts about this feature in the meantime.

[tgodzik]

Did you try it in

bloop/frontend/src/main/scala/bloop/dap/BloopDebuggee.scala

Line 299 in f799e88

val sourceEntry = SourceJar(sourceJar.path)

? If you use SourceDirectory instead of SourceJar for files that aren't ending in .jar?

[dccorona]

Yes, that is the change I made. Specifically:

val sourceEntry = if (source.path.endsWith(".jar")) {
  SourceJar(source.path)
} else {
  SourceDirectory(source.path)
}

However, navigating to definitions still didn't work (and expanding the sources in the Metals sidebar in VSCode caused "internal error", though that may just mean that Metals also needs a patch). I can't be 100% sure it was using my local build though, as I am having some issues getting the local-homebrew-reinstall to work, so I instead used the Metals setting for version to point to the local snapshot. That didn't error, but I don't know how Metals works well enough to say with certainty that it was using my change. I plan to try some things locally to prove that this change is getting used shortly.

[tgodzik]

Ach, the indexing in Metals is not using this logic and I think we have a lot of assumptions about it being jars.

[dccorona]

That was my suspicion - is there any value in putting in a PR for the change above even though it isn't really usable by Metals yet, or do you think it makes more sense to just hold off until the feature can be implemented end-to-end?

[tgodzik]

We can do the change partly for sure, this would at least enable debugging and breakpoints (I hope, I haven't checked that)