Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

VSCode "Reveal Active File" for dependencies no longer works for scala gradle projects #6182

Closed
KrisCien opened this issue Feb 29, 2024 · 0 comments · Fixed by #6213
Closed

VSCode "Reveal Active File" for dependencies no longer works for scala gradle projects #6182

KrisCien opened this issue Feb 29, 2024 · 0 comments · Fixed by #6213
Milestone
Metals v1.3.0

Comments

@KrisCien
Copy link

KrisCien commented Feb 29, 2024 •
edited

Describe the bug

Regression was introduced in metals-vscode 1.27.0 (Metals v1.2.0) for scala gradle based projctes

  1. Open scala project with gradle based build
  2. Open some project source file that imports 3rd party dependency
  3. In text editor click on 3rd party class and open dependency source code in text editor view (note the 3rd party dependency needs to provide *-sources.jar)
  4. switch to Metals view and in Packages section click "Reveal Active File"

The Package view is not updated with location of 3rd party file instead vscode reports error:

Error running command metals.reveal-active-file: Internal error.. This is likely caused by the extension that contributes metals.reveal-active-file.

Additionally the Metals -> Package -> Libraries section now shows source jars as the only project dependencies.

Example gardle project to reproduce:
https://github.com/KrisCien/scala-gradle-example
see issue.mov with recording of reproduce steps

likely regression introduced by changes to MetalsTreeViewProvider#revealResult method in commit 20964af
(note for gradle based builds cannot derive *-sources.jar location from classes jar as gradle cashes those in different folders)

Expected behavior

Expected behaviour:
When in Metals view and "Reveal Active File" clicked while 3rd party dependency file is active in text editor
location in Packages view is updated to location of that file

Operating system

macOS

Editor/Extension

VS Code

Version of Metals

v1.2.0

Extra context or search terms

No response
@kasiaMarek kasiaMarek self-assigned this Mar 5, 2024
@kasiaMarek kasiaMarek mentioned this issue Mar 6, 2024
Closed
tgodzik added a commit to tgodzik/metals that referenced this issue Mar 8, 2024
@tgodzik
improvement: Use dependencyModule for resolving sources
68599a9 
Previously, we would assume that the source jar is in the same directory as the normal jar. Now we use dependencyModules for that and only fallback to the previous logic if we can't find the jar in dependency modules.

This extracts part of the lazy classpath PR

Fixes scalameta#6182
@tgodzik tgodzik mentioned this issue Mar 8, 2024
Merged
tgodzik added a commit to tgodzik/metals that referenced this issue Mar 10, 2024
@tgodzik
improvement: Use dependencyModule for resolving sources
a77686b 
Previously, we would assume that the source jar is in the same directory as the normal jar. Now we use dependencyModules for that and only fallback to the previous logic if we can't find the jar in dependency modules.

This extracts part of the lazy classpath PR

Fixes scalameta#6182
@kasiaMarek kasiaMarek removed their assignment Mar 11, 2024
tgodzik added a commit to tgodzik/metals that referenced this issue Mar 11, 2024
@tgodzik
improvement: Use dependencyModule for resolving sources
de78cd7 
Previously, we would assume that the source jar is in the same directory as the normal jar. Now we use dependencyModules for that and only fallback to the previous logic if we can't find the jar in dependency modules.

This extracts part of the lazy classpath PR

Fixes scalameta#6182
tgodzik added a commit to tgodzik/metals that referenced this issue Mar 12, 2024
@tgodzik
improvement: Use dependencyModule for resolving sources
f606320 
Previously, we would assume that the source jar is in the same directory as the normal jar. Now we use dependencyModules for that and only fallback to the previous logic if we can't find the jar in dependency modules.

This extracts part of the lazy classpath PR

Fixes scalameta#6182
tgodzik added a commit to tgodzik/metals that referenced this issue Mar 12, 2024
@tgodzik
improvement: Use dependencyModule for resolving sources
df46652 
Previously, we would assume that the source jar is in the same directory as the normal jar. Now we use dependencyModules for that and only fallback to the previous logic if we can't find the jar in dependency modules.

This extracts part of the lazy classpath PR

Fixes scalameta#6182
tgodzik added a commit to tgodzik/metals that referenced this issue Mar 12, 2024
@tgodzik
improvement: Use dependencyModule for resolving sources
6b2839f 
Previously, we would assume that the source jar is in the same directory as the normal jar. Now we use dependencyModules for that and only fallback to the previous logic if we can't find the jar in dependency modules.

This extracts part of the lazy classpath PR

Fixes scalameta#6182
tgodzik added a commit to tgodzik/metals that referenced this issue Mar 13, 2024
@tgodzik
improvement: Use dependencyModule for resolving sources
8490a94 
Previously, we would assume that the source jar is in the same directory as the normal jar. Now we use dependencyModules for that and only fallback to the previous logic if we can't find the jar in dependency modules.

This extracts part of the lazy classpath PR

Fixes scalameta#6182
tgodzik added a commit to tgodzik/metals that referenced this issue Mar 13, 2024
@tgodzik
improvement: Use dependencyModule for resolving sources
f116c94 
Previously, we would assume that the source jar is in the same directory as the normal jar. Now we use dependencyModules for that and only fallback to the previous logic if we can't find the jar in dependency modules.

This extracts part of the lazy classpath PR

Fixes scalameta#6182
tgodzik added a commit to tgodzik/metals that referenced this issue Mar 13, 2024
@tgodzik
improvement: Use dependencyModule for resolving sources
a06d983 
Previously, we would assume that the source jar is in the same directory as the normal jar. Now we use dependencyModules for that and only fallback to the previous logic if we can't find the jar in dependency modules.

This extracts part of the lazy classpath PR

Fixes scalameta#6182
tgodzik added a commit to tgodzik/metals that referenced this issue Mar 14, 2024
@tgodzik
improvement: Use dependencyModule for resolving sources
770b45b 
Previously, we would assume that the source jar is in the same directory as the normal jar. Now we use dependencyModules for that and only fallback to the previous logic if we can't find the jar in dependency modules.

This extracts part of the lazy classpath PR

Fixes scalameta#6182
tgodzik added a commit to tgodzik/metals that referenced this issue Mar 14, 2024
@tgodzik
improvement: Use dependencyModule for resolving sources
8e50ed9 
Previously, we would assume that the source jar is in the same directory as the normal jar. Now we use dependencyModules for that and only fallback to the previous logic if we can't find the jar in dependency modules.

This extracts part of the lazy classpath PR

Fixes scalameta#6182
tgodzik added a commit to tgodzik/metals that referenced this issue Mar 14, 2024
@tgodzik
improvement: Use dependencyModule for resolving sources
548ffd7 
Previously, we would assume that the source jar is in the same directory as the normal jar. Now we use dependencyModules for that and only fallback to the previous logic if we can't find the jar in dependency modules.

This extracts part of the lazy classpath PR

Fixes scalameta#6182
tgodzik added a commit to tgodzik/metals that referenced this issue Mar 14, 2024
@tgodzik
improvement: Use dependencyModule for resolving sources
6ff2a72 
Previously, we would assume that the source jar is in the same directory as the normal jar. Now we use dependencyModules for that and only fallback to the previous logic if we can't find the jar in dependency modules.

This extracts part of the lazy classpath PR

Fixes scalameta#6182
tgodzik added a commit to tgodzik/metals that referenced this issue Mar 18, 2024
@tgodzik
improvement: Use dependencyModule for resolving sources
d578eba 
Previously, we would assume that the source jar is in the same directory as the normal jar. Now we use dependencyModules for that and only fallback to the previous logic if we can't find the jar in dependency modules.

This extracts part of the lazy classpath PR

Fixes scalameta#6182
tgodzik added a commit that referenced this issue Mar 18, 2024
@tgodzik
improvement: Use dependencyModule for resolving sources
acae2b9 
Previously, we would assume that the source jar is in the same directory as the normal jar. Now we use dependencyModules for that and only fallback to the previous logic if we can't find the jar in dependency modules.

This extracts part of the lazy classpath PR

Fixes #6182
@tgodzik tgodzik added this to the Metals v1.3.0 milestone Apr 11, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
Metals v1.3.0
3 participants
@tgodzik @KrisCien @kasiaMarek