Dependency Version handling: Buildship 3.1.10.v20240802-1314 cannot resolve all files, Buildship 3.1.9.v20240115-1636 can
Expected Behavior
When importing or refreshing gradle in eclipse I expect the project to resolve all classes as gradle does from the command line.
Current Behavior
When importing or refreshing a gradle project in eclipse 2025-03 with buildship 3.1.10.v20240802-1314 I get the following error-
Failed to notify build listener.
Could not resolve all files for configuration ':myProjectclient:clientRuntimeClasspath'. Could not resolve com.mycompany:myProject-client:[0.0.9, 0.5.0). Required by: project :myProjectclient > project :myProjectlib > project :myOtherProjectlib > Failed to list versions for com.mycompany:myProjectclient. > Unable to load Maven meta-data from ###company-repository-url### > org.apache.http.ssl.SSLInitializationException: NONE (The system cannot find the file specified)
When downgrading to buildship 3.1.9.v20240115-1636 everything works as expected and I can import and refresh the project
Context
This prevents us from using newer versions of eclipse unless we downgrade buildship
Steps to Reproduce
Importing our multiproject build, we do have an internal instance of artifactory but the credentials are provided at runtime
Your Environment
Windows 11 Gradle 7.5.1 Eclipse 2025-03 Java Corretto 17.0.14_7
This looks to be an issue with how buildship is handling the version '[0.0.9, 0.5.0)' should be anything greater than 0.0.9 and less than 0.5.0. I also noticed it will fail with the same error with the syntax- version: '0.0.9+'
I figured out a work around for this. In the eclipse.ini file they have -Djavax.net.ssl.trustStore=NONE deleting this from there I am able to resolve my dependencies.
Why would a jvm arg in the eclipse.ini file have any effect on my gradle refresh if I have my java home set and no args in the preferences > gradle? Seems like its using eclipses vm for the refresh?