vscode-gradle
vscode-gradle copied to clipboard
Fails on class import in included sript for custom repositoty
Extension Name: vscode-gradle Extension Version: v3.12.4 OS Version: openSUSE Leap 15.3 VSCode version:1.71.2
Describe the bug Extension don't treate custom repository inside included script. It fails on an import resolution.
To Reproduce
I created little sample project.
It fails for VSCode plugin, but succeed if I run gradle build in terminal.
In same time, if you move content of included script to the main script instead of apply
command and removes the issue
file, the problem disapears.
Expected behavior No errors in IDE.
Screenshots
Output from "Gradle for Java"
[info] [gradle-server] Picked up JAVA_TOOL_OPTIONS: -Dfile.encoding=UTF-8
[info] [gradle-server] Server started, listening on 38183
[info] Gradle client connected to server
[info] Java Home: /usr/lib64/jvm/java-11-openjdk-11
[info] JVM Args: --add-opens,java.base/java.util=ALL-UNNAMED,--add-opens,java.base/java.lang=ALL-UNNAMED,--add-opens,java.base/java.lang.invoke=ALL-UNNAMED,--add-opens,java.base/java.util=ALL-UNNAMED,--add-opens,java.prefs/java.util.prefs=ALL-UNNAMED,--add-opens,java.prefs/java.util.prefs=ALL-UNNAMED,--add-opens,java.base/java.nio.charset=ALL-UNNAMED,--add-opens,java.base/java.net=ALL-UNNAMED,--add-opens,java.base/java.util.concurrent.atomic=ALL-UNNAMED,-XX:MaxMetaspaceSize=256m,-XX:+HeapDumpOnOutOfMemoryError,-Xms256m,-Xmx512m,-Dfile.encoding=UTF-8,-Duser.country=US,-Duser.language=en,-Duser.variant
[info] Gradle User Home: /home/olga/.gradle
[info] Gradle Version: 7.5.1
[info] CONFIGURE SUCCESSFUL in 10s
[info] Found 18 tasks
Does the bug still exist if you disable all other extensions? Yes
Additional context I put fake auth params in repository, but in the localhost I use real authentication. There are no problem with custome repository.
When I try to reproduce this issue I'm finding an extra error report here:
it seems that I can't resolve the given script dependencies.
Also, you mentioned error can be found. I think it's related to buildscript classpath resolving. Can you see only the error you mentioned?
OK, I just changed actual paths. Another thing: we have our own network, and even real paths will not acceptable outside. I will create such packages latter on GitHub, for you will able to reproduce the issue.
OK, I replaced our own repository in Gradle buildscript section with MavenCentral.
I put buildscript
section in included file - db.gradle
, and unfortunately the problem isn't reproduced: https://github.com/olgapshen/vscode_gradle_issue/commit/5d3b24232bb8aed261a62c99bfe7f25425631b99
I see, that problem reproducing just with repositories which requests authentication... Can you substitute com.fasterxml.jackson.core:jackson-databind:2.14.0
with you own package and add your own Maven GitHub repository with auth tokens? Then make simple import and output depending on the class in the dbschema
task.
I can imagine the issue is related to authentication, and I'm wondering if your redhat.java
extension works in your environment without extra configuring.
Could you try to configure the authentication in java.import.gradle.jvmArguments
? just refer to https://github.com/redhat-developer/vscode-java/wiki/Using-a-Proxy, but setting java.import.gradle.jvmArguments
instead of java.jdt.ls.vmargs
.
Hi! Are you sure I need use the configuration you provide there? We don't have any proxy... And I doubt I have auth problems, thus I don't have problem when I put buildscript
block in the root.
OK, may be I didn't explain my self well.
This follow two screenshots are OK situation.
build.gradle file
db.gradle file
This follow two screenshots are BAD sitation.
build.gradle file
db.gradle file
I just want put buildscript
inside db.gradle
file and not in build.gradle
.
thanks for the detail explanation! I'll take a look tomorrow
just tried to reproduce it but failed:
I can successfully resolve the given type from private package (custom repository).
Did you try directly add the dependency to project implementation
configuration and see if it's available in your Java project?
You need put it NOT in build.gradle
file, but in a file INSIDE a folder.
Create file by the path: gradle/inner.gradle
at project root, and put the buildscript
block there.
my fault, I can reproduce it now.
Wonderful!!! Just to be sure. You can reproduce the problem, right?
Yes, I can reproduce, but it seems that the problem is related to Gradle itself. See: https://github.com/gradle/gradle/issues/5003, and the answer here:
Yes, this is expected, because script plugins (e.g. publishing.gradle) and project build scripts do not share a classloader hierarchy. For the Groovy DSL the best recommendation I have right now is to put your plugin dependencies in buildSrc/build.gradle, because then they will be visible to all scripts.
Since we're using Gradle API project.getBuildScript().getScriptClasspath() to get the groovy compile classpath: https://github.com/microsoft/vscode-gradle/blob/65aad76b7a1a6333344bca66302fbd6a1adc66c9/gradle-plugin/src/main/java/com/microsoft/gradle/GradleProjectModelBuilder.java#L87-L92
it's might be hard for us to get the exact classpath of db.gradle
, since the entry is build.gradle
and I don't find any way to get the classpath of another gradle script.
So I'm afraid a better solution now is that we do not publish diagnostics of any gradle file expect the root build.gradle.
No, there is no problem in Gradle, thus following case is working there:
// build.gradle
apply from: 'publishing.gradle'
//publishing.gradle
buildscript {
repositories { gradlePluginPortal() }
dependencies { classpath 'io.codearte.gradle.nexus:gradle-nexus-staging-plugin:0.11.0' }
}
apply plugin: io.codearte.gradle.nexus.NexusStagingPlugin
tasks.withType(io.codearte.gradle.nexus.BaseStagingTask) { println '2: ' + it }
works properly, three tasks printed once
About your link: vscode-gradle/gradle-plugin/src/main/java/com/microsoft/gradle/GradleProjectModelBuilder.java
I will review the source code of the plugin, and together we will think how to fix the issue. I will try to end up tomorrow with it.
No, there is no problem in Gradle
There is no problem in Gradle for sure, my point is that we can't query the classpath of other gradle file (publishing.gradle
in the above snippet) since the scripts do not share classloader hierarchy. With no classpath we can't compile it correctly in our extension.
Any contributions or thoughts are welcome :)
Hi! I still on my way to learn the plugin code, but now I put attension, that even repositories
block I can not extract to outer file.
And more sad think is that NO LOGS says that repositories in the outer file are not treated.
So all this is a significant problem.
Yes, by the way, I feel that most of the troubles in Language Support for Java(TM) by Red Hat v1.12.0
I switched off all gradle plugins, and I still have the troubles while Java project build.
But I guess both of them use same libraries.
I'd like to mention that the extension redhat.java
(you mentioned Language Support for Java(TM) by Red Hat v1.12.0) is responsible for importing the java project, and find issues about that. It will reports errors with "Java" error code.
and the extension vscode-gradle
is responsible for the Gradle build and reports errors with "Gradle" error code, like what in your screenshot:
It just extract information from the Gradle build use Gradle libraries (Gradle TAPI), currently, there is no interactive between these two extensions. So I think you can simpliy disabled the
redhat.java
extension temporary if you want to find issues related to gradle extension.
The plugin just defines a Gradle model, which contains the information we are interested in from the Gradle build. The entry to get the model can be found at: https://github.com/microsoft/vscode-gradle/blob/db4104b727fb528e1127f26b1fd0a44c4adce939/gradle-server/src/main/java/com/github/badsyntax/gradle/handlers/GetBuildHandler.java#L124
and the logics to build the model can be found here: https://github.com/microsoft/vscode-gradle/blob/db4104b727fb528e1127f26b1fd0a44c4adce939/gradle-plugin/src/main/java/com/microsoft/gradle/GradleProjectModelBuilder.java#L83
OK, thank you for pointing me the entry points. I just finish with my urgent tasks in my work and I will tryto find solution.