Relative Paths in the project gradle.properties do not work

[xendren]

Extension Name: vscode-gradle Extension Version: 2.4.13 OS Version: Windows 10 VSCode version: 1.43.2

Describe the bug We add an entry in the gradle.properties file to override the trust authority to use our local artifact repository instead of Maven Central. Executing using the gradle wrapper from Command prompt works fine. Executing from the Gradle Tasks explorer gives the error that it can't find the cacerts file specified. If we give full path in the properties file, then it works. This is not acceptable for our processes.

Update: Looks like it is executing the tasks from the /User//.vscode/extensions/... directory when applying the Java parameter to set the truststore. I'm guessing Java parameters are being parsed/applied in different context than other gradle.properties values.

To Reproduce Define a relative path in the gradle.properties file of any project. Execute from the Gradle Tasks Explorer.

Expected behavior Relative paths should be supported from within gradle.properties file.

Does the bug still exist if you disable all other extensions? Yes

Additional context Add any other context about the problem here.

[badsyntax]

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?

[xendren]

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>

[badsyntax]

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.

[badsyntax]

@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

[xendren]

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.

[badsyntax]

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

[xendren]

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

[xendren]

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.

[xendren]

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.

[badsyntax]

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

[badsyntax]

Refs:

• https://github.com/redhat-developer/vscode-java/issues/279
• https://github.com/redhat-developer/vscode-java/issues/1070

[badsyntax]

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.