You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
org.springframework.boot.gradle 3.1.0 can't be resolved,
(Incompatible because this component declares an API of a component compatible with Java 17 and the consumer needed a runtime of a component compatible with Java 11
- Other compatible attribute:
- Doesn't say anything about its target Java environment (preferred optimized for standard JVMs))
the language support plugin is uses java 11 as default to import, even if the seourceCompatibility has been set and
the gradle.properties org.gradle.java.home=/usr/lib/jvm/java-17-openjdk-amd64 on project level has been set (root folder)
The only way was to resolve is "java.import.gradle.java.home": "/usr/lib/jvm/java-1.17.0-openjdk-amd64", which is painful to figure out, intellij is behaving similarly (Gradle JVM needs to be set -> hasn't tested the gradle.properties in this case)
Expected Result
I would have expected:
a) whatever the JAVA_HOME sais, and the java.import.gradle.java.home is not set,
it's using the JAVA_HOME for gradle import also. (command line is using it)
b) if gradle.properties has been set is picking up java folder from there
It is the behavior being described in the official gradle manual.
Additional Informations
I'm using gradle for java plugin also.
The difference between intellij and vscode was, that the Gradle JVM had a default value. (randomly selected one)
After several attempt and screw up, cleaning up language server (ctrl+shift+p -> relevant command) didn't help, just removing all the workspace folder,
remove the project from workspace and restart and add back the project.
In this case java classes has been identified as non-project files!
JAVA_HOME has been automatically set, while java 17 installer was running.
JAVA_HOME => /usr/lib/jvm/java-17-openjdk-amd64
The problem, as i said is plugin one.
"./gradlew build" from terminal was perfectly fine, without any configuration.
It was reacting also to gradle.properties. (i set to java 11, and it failed right away with the error above)
The plugin either the gradle for java, or the language support is hard coding java 11, because it was the first version from which these plugins have got support. I had to upgrade to java 11 from java 8, as it was not working. (a year ago)
It's causing issues only on gradle import, but building the source code to java 17. The plugin itself is printing out java 17, and screwing up at gradle import.
plugins {
id 'java'
id 'org.springframework.boot' version '3.1.0'
id 'io.spring.dependency-management' version '1.1.0'
}
group = 'com.raxim'
version = '0.0.1-SNAPSHOT'
sourceCompatibility = '17'
when id java is running picking up the 17 source compatibility (using java 17), but the
id 'org.springframework.boot' version '3.1.0' is trying to make a gradle import on java 11.
What went wrong:
A problem occurred configuring root project 'myscoutee'.
Could not resolve all files for configuration ':classpath'.
Could not resolve org.springframework.boot:spring-boot-gradle-plugin:3.1.0.
Required by:
project : > org.springframework.boot:org.springframework.boot.gradle.plugin:3.1.0
> No matching variant of org.springframework.boot:spring-boot-gradle-plugin:3.1.0 was found. The consumer was configured to find a library for use during runtime, compatible with Java 11, packaged as a jar, and its dependencies declared externally, as well as attribute 'org.gradle.plugin.api-version' with value '8.1.1' but:
- Variant 'apiElements' capability org.springframework.boot:spring-boot-gradle-plugin:3.1.0 declares a library, packaged as a jar, and its dependencies declared externally:
- Incompatible because this component declares a component for use during compile-time, compatible with Java 17 and the consumer needed a component for use during runtime, compatible with Java 11
- Other compatible attribute:
- Doesn't say anything about org.gradle.plugin.api-version (required '8.1.1')
- Variant 'javadocElements' capability org.springframework.boot:spring-boot-gradle-plugin:3.1.0 declares a component for use during runtime, and its dependencies declared externally:
- Incompatible because this component declares documentation and the consumer needed a library
- Other compatible attributes:
- Doesn't say anything about its target Java version (required compatibility with Java 11)
- Doesn't say anything about its elements (required them packaged as a jar)
- Doesn't say anything about org.gradle.plugin.api-version (required '8.1.1')
- Variant 'mavenOptionalApiElements' capability org.springframework.boot:spring-boot-gradle-plugin-maven-optional:3.1.0 declares a library, packaged as a jar, and its dependencies declared externally:
- Incompatible because this component declares a component for use during compile-time, compatible with Java 17 and the consumer needed a component for use during runtime, compatible with Java 11
- Other compatible attribute:
- Doesn't say anything about org.gradle.plugin.api-version (required '8.1.1')
- Variant 'mavenOptionalRuntimeElements' capability org.springframework.boot:spring-boot-gradle-plugin-maven-optional:3.1.0 declares a library for use during runtime, packaged as a jar, and its dependencies declared externally:
- Incompatible because this component declares a component, compatible with Java 17 and the consumer needed a component, compatible with Java 11
- Other compatible attribute:
- Doesn't say anything about org.gradle.plugin.api-version (required '8.1.1')
- Variant 'runtimeElements' capability org.springframework.boot:spring-boot-gradle-plugin:3.1.0 declares a library for use during runtime, packaged as a jar, and its dependencies declared externally:
- Incompatible because this component declares a component, compatible with Java 17 and the consumer needed a component, compatible with Java 11
- Other compatible attribute:
- Doesn't say anything about org.gradle.plugin.api-version (required '8.1.1')
- Variant 'sourcesElements' capability org.springframework.boot:spring-boot-gradle-plugin:3.1.0 declares a component for use during runtime, and its dependencies declared externally:
- Incompatible because this component declares documentation and the consumer needed a library
- Other compatible attributes:
- Doesn't say anything about its target Java version (required compatibility with Java 11)
- Doesn't say anything about its elements (required them packaged as a jar)
- Doesn't say anything about org.gradle.plugin.api-version (required '8.1.1')
pls. don't confuse that i have upgraded the 8.1.1 lately, same problem...It happens inside the vscode, but not from command prompt (I have also multi jdk, 17 is default, but i have 8 and 11 installed also)
/usr/lib/jvm/java-1.17.0-openjdk-amd64 or /usr/lib/jvm/java-17-openjdk-amd64 does not make that much difference, the 1.17 is a simplink to the 17, which is a simplink to an openjdk-17..."really nice stuff". however installer set up the JAVA_HOME not me.
Then the next version of the plugin needs to do something with your
solution, as that jdt.ls and other things can't be that manual to cause
months of trouble.
My feeling also there is some stability issue, which hasn't happened
before. Java files are not parsed, sometimes code is not clickable.
The code also, if something wrong in the block.
For example in methods or java lambda, then i need to revert back and start
over. (brackets etc.) Too many times i need to restart vscode or cleanup
the cache.
If there is a never ending process in debug, that one also would be
helpfull, if it could have been identified in the task bar, or from the
vscode ui, to kill.
Peter
On Thu, 27 Jul 2023, 06:20 Matthew Lonis, ***@***.***> wrote:
I have been able to resolve this with the following minimal settings.json:
{
"java.configuration.runtimes": [
{
"name": "JavaSE-17",
"path": "/usr/lib/jvm/java-17-openjdk-amd64",
"default": true
}
],
"java.jdt.ls.java.home": "/usr/lib/jvm/java-17-openjdk-amd64"
}
I am using WSL Ubuntu to install OpenJDK via sudo apt install
openjdk-17-jdk, so your paths might be different depending on the OS and
the flavor of JDK.
My $JAVA_HOME is set to export
JAVA_HOME=/usr/lib/jvm/java-17-openjdk-amd64.
I did not need to set the java.import.gradle.java.home at all.
—
Reply to this email directly, view it on GitHub
<#3136 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AK3XT6XARHQZF4PJJFRGEN3XSHUCHANCNFSM6AAAAAAY2FDMDA>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
I would have expected:
a) whatever the JAVA_HOME sais, and the java.import.gradle.java.home is not set,
it's using the JAVA_HOME for gradle import also. (command line is using it)
The exact Precedence is below.
settings.json java.import.gradle.java.home
settings.json java.jdt.ls.java.home (Default is Red Hat embedded JRE)
settings.json java.home (deprecated)
env var JAVA_HOME
env var PATH
The design problem is that the Gradle extension references java.jdt.ls.java.home for the Red Hat extension language server. This is counter-intuitive.
Activity
fssrepository commentedon Jun 4, 2023
cross attached:
microsoft/vscode-gradle#1340
snjeza commentedon Jun 4, 2023
@fssrepository I can't reproduce the issue.
Could you run the following commands:
fssrepository commentedon Jun 4, 2023
openjdk version "17.0.7" 2023-04-18
OpenJDK Runtime Environment (build 17.0.7+7-Ubuntu-0ubuntu120.04)
OpenJDK 64-Bit Server VM (build 17.0.7+7-Ubuntu-0ubuntu120.04, mixed mode, sharing)
snjeza commentedon Jun 4, 2023
You should set JAVA_HOME.
You have to check if it is
/usr/lib/jvm/java-1.17.0-openjdk-amd64or/usr/lib/jvm/java-17-openjdk-amd64fssrepository commentedon Jun 4, 2023
JAVA_HOME has been automatically set, while java 17 installer was running.
JAVA_HOME => /usr/lib/jvm/java-17-openjdk-amd64
The problem, as i said is plugin one.
"./gradlew build" from terminal was perfectly fine, without any configuration.
It was reacting also to gradle.properties. (i set to java 11, and it failed right away with the error above)
The plugin either the gradle for java, or the language support is hard coding java 11, because it was the first version from which these plugins have got support. I had to upgrade to java 11 from java 8, as it was not working. (a year ago)
It's causing issues only on gradle import, but building the source code to java 17. The plugin itself is printing out java 17, and screwing up at gradle import.
plugins {
id 'java'
id 'org.springframework.boot' version '3.1.0'
id 'io.spring.dependency-management' version '1.1.0'
}
group = 'com.raxim'
version = '0.0.1-SNAPSHOT'
sourceCompatibility = '17'
when id java is running picking up the 17 source compatibility (using java 17), but the
id 'org.springframework.boot' version '3.1.0' is trying to make a gradle import on java 11.
fssrepository commentedon Jun 4, 2023
A problem occurred configuring root project 'myscoutee'.
pls. don't confuse that i have upgraded the 8.1.1 lately, same problem...It happens inside the vscode, but not from command prompt (I have also multi jdk, 17 is default, but i have 8 and 11 installed also)
fssrepository commentedon Jun 4, 2023
/usr/lib/jvm/java-1.17.0-openjdk-amd64 or /usr/lib/jvm/java-17-openjdk-amd64 does not make that much difference, the 1.17 is a simplink to the 17, which is a simplink to an openjdk-17..."really nice stuff". however installer set up the JAVA_HOME not me.
snjeza commentedon Jun 4, 2023
Could you try
shijo-keyvalue commentedon Jun 11, 2023
I am also facing the same problem.
hugo-marello commentedon Jul 12, 2023
Same problem here, the plugin doesn't go well with jdk 17
fssrepository commentedon Jul 27, 2023
cypher256 commentedon May 21, 2024
The exact Precedence is below.
java.import.gradle.java.homejava.jdt.ls.java.home(Default is Red Hat embedded JRE)java.home(deprecated)JAVA_HOMEPATHThe design problem is that the Gradle extension references
java.jdt.ls.java.homefor the Red Hat extension language server. This is counter-intuitive.