Issues with vscode multi-root and groovy classes in lib/

Ask for help
1

Hi,

I’m running into some issues when using custom groovy classes in lib, while using multi-root workspaces and the vscode extension.

We have a wrapper around a nextflow pipeline, and our directory structure looks like this:

root
├─ project.code-workspace
├─ src
│   └─ nf-pipeline
├─ dir_1
├─ files...

When my project.code-workspace is configured as follows:

{
    "folders": [
        {
            "path": "src/nf-pipeline"
        },
        {
            "path": "dir_1"
        }
    ]
}

…the LSP works perfectly. Opening Nextflow files inside src/nf-pipeline correctly detects all custom Groovy classes in src/nf-pipeline/lib/ (e.g., hover tooltips show function calls and signatures).

Now, for the problem: I need to have the root/files... accessible alongside the pipeline, so I modified the workspace file, appending the following to the “folders”:

        {
            "path": "."
        }

However, as soon as I include "path": ".", the LSP stops detecting the Groovy classes in lib (resulting in “Class not defined” errors), even though the LSP itself is still running. For instance, hovers still work for workflows, showing take and emit blocks, but not for the classes in lib (and all my .nf files are marked red with errors everywhere)

I’ve tried several things:

  • ignoring the nf-pipeline folder in the "path" : ".", using settings.files.ignore
  • setting the java home configuratin manually, at the user, workspace and folder levels, to avoid relying on the vscode extension’s findJava function
  • looking at the Nextflow Language Server output in both cases (which does not change at all, we get the same messages)
  • enabled debug on hover, but again, the hover is identical both on the working and non-working cases.

Any Ideas?
I’m looking for guidance on how to have the parent root folder included in the workspace without losing the LSP’s ability to resolve classes in lib. The extension has been amazing so far, making development much easier (thanks a bunch btw!)

Any help or pointers would be greatly appreciated!

2

I tried to make a minimal reproducible example (in github here: https://github.com/gerbeldo/test-nf-vscode), and unfortunately I was not able reproduce the issue, so there might be some other problem with our project (which is quite large) that might be confusing the nextflow LSP. I’m even more confused now :grimacing:

3

I think this directory structure is simply not supported by the language server. The lib directory needs to be in the top-level because the language server expects the workspace root to correspond to a Nextflow pipeline.

You could create a symlink of files in the pipeline directory so that you can have the pipeline directory as the root while also showing files. I think you would have to do that anyway if you wanted the pipeline to be able to access files.

4

Thanks for the input. Our pipeline does not need access to anything outside of its directory, so symlinking might be a bit too much.

For now I resorted to just opening two vscode instances, one to work on the nextflow code, with the pieline and /lib in the root, and a workspace with everything else.

From what I’ve seen on github we’ll need to make the /lib functions into a plugin anyway (as we depend on @Grab), so this just might go away eventually.

Thanks again for your time!

1 Like
5

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.