-
Notifications
You must be signed in to change notification settings - Fork 321
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.
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
VSCode "Reveal Active File" for dependencies no longer works for scala gradle projects #6182
Milestone
Comments
tgodzik
added a commit
to tgodzik/metals
that referenced
this issue
Mar 8, 2024
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 10, 2024
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 11, 2024
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
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
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
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
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
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
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
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
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
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
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
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
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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Describe the bug
Regression was introduced in metals-vscode 1.27.0 (Metals v1.2.0) for scala gradle based projctes
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
The text was updated successfully, but these errors were encountered: