Hi. Thanks for the bug report. Are you able to provide an example (like a build.gradle gradle.properties file) to help me reproduce this bug?

Yes. It just has one line to specify the company truststore with our self-signed CA cert chain:

org.gradle.jvmargs=-Djavax.net.ssl.trustStore="../../../../modules/Common/security/cacerts" -Djavax.net.ssl.trustStorePassword=<trust-password>

Thanks for this. I've been able to replicate this by setting a relative path for java home directory (easier than setting up a custom truststore):

EG:

org.gradle.java.home=../../../../../Library/Java/JavaVirtualMachines/adoptopenjdk-8.jdk/Contents/Home

This seems to be a generic issue with the gradle tooling api. I will keep investigating potential fixes.

@xendren i'm curious, does this work other editors, eg intellij?

you mention:

If we give full path in the properties file, then it works. This is not acceptable for our processes.

does this imply this works with other editors? there seems to be a related bug for intellij: https://youtrack.jetbrains.com/issue/IDEABKL-7164

I don't have IntelliJ installed, but it looks like it is the same issue. This seems more of an issue with how extensions execute in the IDE's rather than a Gradle problem, correct?

To answer your previous question, if we use the absolute path in the gradle.properties file, it works as expected. Unfortunately, that is not a viable work-around for us since we can't control the location of the cloned repository on every developer's environments. It seems that Gradle should supply Gradle level command line properties to support this like Maven does, or at the very least, support the Maven properties that already exist.

It's hard for me to say where the issue lies. The point of the embedded gradle (using the gradle tooling api) is that builds are supposed to "just work" regardless of the process initiating the build, so this could be seen as a bug in the gradle tooling api, or it could be "as designed" (maybe relative paths should not be used in gradle.properties.)

I've requested some help/advice from the gradle community: https://discuss.gradle.org/t/tooling-api-support-for-relative-paths-in-gradle-properties/35579

If I run the gradle task for the same project outside of VS Code, it works fine with the relative path.

Also, relative paths work in other contexts. It seems that having JVM parameters in the gradle.properties file gets added earlier than once the gradle build prepares to execute.

Although not a great solution, the only alternative I see is to somehow convince Gradle to not do SSL verification for our internal Nexus server. That is how we solved the problem using Maven. It has parameters for ignoring SSL Verification. Unfortunately, Gradle does not use those parameters and does not seem to have its own.

Our developer has figured out a work around for the time being. He is using the "Task Explorer" extension to surface some custom added tasks in the project's tasks.json file. Those tasks just use the "cwd" property to have the task run from the workspace directory. This allows gradle to run the builds with the correct relative path. This is manageable since all of these changes can be applied to files contained within the project repository. Unfortunately, this bypasses using the "Gradle Tasks" extension.

I've found a fix for this. I'll try release the fix asap.

Refs:

• [gradle] Accessing files in build directory redhat-developer/vscode-java#279
• java.home Path Cannot be Relative redhat-developer/vscode-java#1070

Actually, i'm sorry, it's not a good fix. I'm still investigating a proper fix for this, but I can't make any estimates as to when I can do it.