Automatic source discovery fails for jars not built with Maven

[linghengqian]

• Currently, java.maven.downloadSources can only be turned on or off, and if it's off, there's no way to download the source code of a single Maven dependency.

• 
• 

• I expect that an interactive option can be added to java.maven.downloadSources. What I know is something similar to IntelliJ IDEA, where opening a .class file reveals an option to Download Sources or Choose Sources. Choose Sources can also be used to shade Java packages about org.apache.maven.plugins:maven-shade-plugin. I'm using IntelliJ IDEA as an example because I can't think of anywhere else outside of IntelliJ IDEA that offers this functionality.

[fbricon]

Normally java.maven.downloadSources should be used to automatically download all Maven dependency sources at once, during project import, which makes it slower. If disabled, when you're opening a file from a single Maven dependency, sources should be automatically fetched. If it doesn't work, something's wrong.

[linghengqian]

If it doesn't work, something's wrong.

• Then I would say it looks like this feature isn't working. Or rather, I don't see any log output showing what the extension is downloading. Is no log output normal behavior under the default configuration?
• When I open java.maven.downloadSources, I can clearly see a wheel icon next to it displaying text that the extension is downloading source code and javadoc.
• 

[fbricon]

java.maven.downloadSources is effective on project import, i.e when you (re)open vs code. You can enable it, restart and check the contents of ~/.m2/repository/org/springframework/spring-tx/[version]/ after you reopen vscode.

The weird thing is the failure to download sources when opening a spring-tx .class. If you take another dependency, like

<dependency>
    <groupId>org.apache.commons</groupId>
    <artifactId>commons-lang3</artifactId>
    <version>3.20.0</version>
</dependency>

the sources are properly downloaded/attached when opening one of its classes.

The only thing I can think of right now is the spring jars missing the maven metadata used to identify the GAV coordinates. But there should be other fallback mechanisms to workaround it. I'll need to investigate further.

[linghengqian]

This doesn't seem to require a separate demo project. From my perspective, as long as java.maven.downloadSource is turned off, opening any project using Maven and trying to open any third-party Maven dependency Java class will not trigger the download of source code or generate any logs; instead, I can only see the classes supposedly decompiled by IntelliJ IDEA.

Incidentally, I didn't install the Linux version of IntelliJ IDEA on the WSL distribution. I also didn't use IntelliJ IDEA on Windows with the WSL distribution via Native Mode or the JetBrains gateway.

[fbricon]

So the issue is definitely caused by jars missing maven metadata (i.e. were not built by Maven). Since the jar doesn't contain the GAV as maven properties, we try to identify the jar GAV by its SHA1 hash, by querying https://search.maven.org/, but there's a problem there. For spring-tx 7.0.2 for instance, the SHA1 is 4fd7a9ae8a0c4490c66c7030024d2ec715e2f63e, but the https://search.maven.org/solrsearch/select?q=1:4fd7a9ae8a0c4490c66c7030024d2ec715e2f63e&rows=1&wt=json query doesn't return any result.

We should be able to work around that though.

And BTW, Fernflower is the name of the decompiler built by JetBrains. They asked us to mention Intellij IDEA in the decompiled source.

[linghengqian]

I'm wondering if I should update the issue title? It seems this only involves an untested case.

[fbricon]

@linghengqian you can try the latest vscode-java pre-release.

[linghengqian]

you can try the latest vscode-java pre-release.

• A belated reply.
• But I discovered something even more perplexing: after switching to the pre-release version, I closed java.maven.downloadSources, and after selecting Clean Workspace in the JAVA PROJECTS menu, I found that I could no longer enter the decompilation state of a class using Ctrl + left mouse button. All classes have changed from green to gray.
• 
• As far as I remember, once I open java.maven.downloadSources, these classes turn green, and then I can access them by Ctrl + left mouse button.
• 
• Does this mean that if I want to test changes in the current pre-release version, I should first open java.maven.downloadSources to let the VS Code extension download the source code of the project's dependencies, then close java.maven.downloadSources, then add a previously unused dependency to pom.xml, and then try something like Ctrl + left mouse button?

[linghengqian]

• I tested it and found that I had to run rm -rf $HOME/.m2/repository/ on my Ubuntu 24.04 WSL to get the VS Code extensions working properly again. Interesting, it seems like something wasn't downloaded from some place I wasn't aware of.
• 
• I've confirmed that the changes in the pre-release version are effective. I can now see the source code for org.springframework.transaction.support.TransactionCallbackWithoutResult while keeping java.maven.downloadSources turned off, and the VS Code extension is showing a spinning circle indicating the source code is downloading. However, the download is too fast for me to take a screenshot.
• 
• Should I close this issue?