0

The presence of an HKEY_CURRENT_USER\Software\Microsoft\Command Processor\Autorun causes a java test to fail. Github repo to test this out : https://github.com/ajorpheus/final-frontier

This is a follow-up question after this happened.

Summary : Apparently a registry hack which allows a command to be run every time the cmd prompt is opened, adversely affects the Java process.

To begin with I thought, that perhaps it was the fact that 'mvn clean test' actually resolves to 'mvn.bat clean test'. However, I tried extracting the java.exe command contained in the mvn.bat file and tried using that directly, but got the same issue.

Any thoughts about why this might be happening ?

Update

Value of the Autorun entry is : cd /d "c:\dev"

Error message is as follows:
java.lang.RuntimeException: Error writing to file: some-dir/target/generated-resources/stuff.xmlwith the following error: Couldn't create dir: some-dir\target\generated-resources at com.test.build.TestFileCreation.createDirectoryTest

Update2

As @NilsH suggested, I've confirmed that the current working directory in both the cases is the same.

Update3

Added a maven profile which sets maven-surefire-plugin's forkMode to never. This profile causes the test to pass irrespective of whether the registry hack is there or not.

Community
  • 1
  • 1
Ashutosh Jindal
  • 18,501
  • 4
  • 62
  • 91
  • 2
    What is the value of the reg entry? And what is the error? – NilsH Apr 27 '13 at 08:23
  • @NilsH, Updated my answer with the details. These are also present in the Github repo's README : https://github.com/ajorpheus/final-frontier – Ashutosh Jindal Apr 27 '13 at 09:36
  • 1
    Try to add `System.out.println(new File("./").getAbsolutePath());` in the test and se what the actual working directory is in both cases. That might shed some light on it. (i don't have Windows, so I can't test it) – NilsH Apr 27 '13 at 14:12
  • @NilsH, The absolute path of the current working directory is the same in both the cases. I have pushed up a [**patchset**](https://github.com/ajorpheus/final-frontier/commit/b6831da764bae6fbf66ddb8ca49e807b0bd3d6eb) to show this. – Ashutosh Jindal Apr 28 '13 at 08:23

1 Answers1

2

When the surfire plugin execute the test in a forked environment, it starts a new cmd process. For this environment the registry hack will set the working directory to "c:\dev" and the JVM is started from within.

parent.exists()

Resolves the path against the directory from which the JVM was started. Which means the test checks the presence of file "C:/dev/some-dir/target/generated-resources/stuff.xml".

parent.getAbsoluteFile().exists()

This checks the presence of the file with it's absolute name, the one you expected to check.

see also the EVALUATION comment for this filed JDK bug
4483097 : File returned by getAbsoluteFile() may not refer to the original file

SubOptimal
  • 22,518
  • 3
  • 53
  • 69
  • `When the surfire plugin execute the test in a forked environment, it starts a new cmd process`, would it be possible to have an authoritative reference for this ? Thanks !! – Ashutosh Jindal May 01 '13 at 08:55
  • @AshutoshJindal Hi, when you run maven in debug mode you see a new invokation of cmd. `[DEBUG] boot classpath: d:\maven\repository\org\apache\maven\surefire\surefire-booter\2.14.1\surefire-booter-2.14.1.jar ... Forking command line: cmd.exe /X /C "C:\PROGRA~1\Java\jdk170\jre\bin\java -jar ...` I setup a small project using JNI to get the directory from which the JVM was invoked. [https://github.com/SubOptimal/getcwd.git](https://github.com/SubOptimal/getcwd.git) – SubOptimal May 02 '13 at 23:05
  • That's exactly what I was looking for! Thanks for taking the time out to investigate this. Awesome !! – Ashutosh Jindal May 03 '13 at 07:36
  • @AshutoshJindal Thanks for the bounty points. The investigation and setting up the tiny project was a pleasure for me. – SubOptimal May 03 '13 at 21:42