kelemen / netbeans-gradle-project

This project is a NetBeans plugin able to open Gradle based Java projects. The implementation is based on Geertjan Wielenga's plugin.
172 stars 57 forks source link

Current directory when running Gradle script is not project directy, but root directory of disk #380

Closed ksilz closed 6 years ago

ksilz commented 6 years ago

Hello,

I've customized my Gradle build for a "Spring Boot Fat JAR" project so that it updates a build file and creates a ZIP file at the end. This doesn't work when running the Gradle tasks in Netbeans because the "Java current directory" is the root directory of my hard disk:

running in netbeans

When running the same Gradle script from the terminal, the "Java current directory" is the project directory, as it should be:

running in terminal

This is the test project used above:

TestDirectory.zip

Below's my environment data. I'm using version 1.4.3 of the Gradle plugin:

Product Version: NetBeans IDE 8.2 (Build 201609300101) Updates: NetBeans IDE is updated to version NetBeans 8.2 Patch 2 Java: 1.8.0_162; Java HotSpot(TM) 64-Bit Server VM 25.162-b12 Runtime: Java(TM) SE Runtime Environment 1.8.0_162-b12 System: Mac OS X version 10.13.3 running on x86_64; UTF-8; de_DE (nb) User directory: /Users/Karsten/Library/Application Support/NetBeans/8.2 Cache directory: /Users/Karsten/Library/Caches/NetBeans/8.2

Is there a setting I need to change to have the Gradle build script run in the project directory? Or is this a bug?

kelemen commented 6 years ago

The current working directory is undefined for a Gradle build. You must not rely on it. Instead you could always write something like file('relative-path') which resolves the path against the project directory.

kelemen commented 6 years ago

That it works from the command line does not mean much because Gradle's Tooling API does not support specifying the current working directory. The only possible way for me is to change the global system property user.dir within NB. However, that would affect every other part of NB and so I don't want to do it.

ksilz commented 6 years ago

Thank you for the hint! I now use the build directory to get the working directory and then access files relative to this working directory:

final String workingDir = project.buildDir.toString() + "/../"
File propsFile = new File(workingDir + 'src/main/resources/build-version.properties')
kelemen commented 6 years ago

It is much better to write this instead:

// Project.file resolves relative paths against the project directory
File propsFile = file('src/main/resources/build-version.properties')

or a more robust code would be:

File propsFile = new File(souceSets.main.resources.srcDirs[0], 'build-version.properties')

The above code snipets yield the same result as you code.

ksilz commented 6 years ago

The code you showed is why I filed this issue in the first place. As you said on Mar 29:

The current working directory is undefined for a Gradle build. You must not rely on it.

Still, the code works in terminal on the Mac and in Intellij on Mac. I had to change it to the code above to make it also work in Netbeans.

kelemen commented 6 years ago

The code works in terminal only if you cd into the appropriate working directory first. That is not necessarily the case. You can run Gradle tasks from any directory on any project if you want to and it would break on command line as well. Also, the Gradle spec. explicitly states that the current working directory is undefined. That is, it will be something but you cannot rely on its value (if it works, you are just "lucky" but your script is still considered broken).

kelemen commented 6 years ago

Also, it works in IntelliJ because they chose to set the internal current working directory temporarily within the IDE which is a hack and since there is only a single current working directory per process, I would set that for every code living inside NB which is not nice to the plugin ecosystem. Also, if you were to run two tasks in parallel, then it can still fail (though the chances are low) even in IntelliJ. By the way, Eclipse does the same, so even if I add this hack to allow broken scripts to work, your script would still be broken in Eclipse.