I don't think this is the right way to solve it. I would prefer that the problematic symlinks are created before the unittest is executed, instead of checking the code out with extra flags. Should be possible, right?

I would prefer that the problematic symlinks are created before the unittest is executed

Modify src/test/resources is evil :-), so a way could be to copy src/test/resources/symlinks/src in target and update symlinks if not correcly cloned. With that all test datas are kept in SCM (no mixed hard & dynamically generated UT datas, more sustainable for comprehension), and no conditional flags about UT execution.

I will update this PR like that if no objection.

Sure, adjust it under target/test-classes is a nice way to solve this.

adjust it under target/test-classes is a nice way to solve this.

Some mechanisms already exists for that in UT (target/test/io/ directory), I will reuse it.

Finally, hard to deal without re-creating symlink completely.

This scenario works:

git clone [-c core.symlinks=true] https://github.com/codehaus-plexus/plexus-utils.git
cd plexus-utils
git pull origin pull/25/head
mvn clean test

With this matrix:

Ready for review if necessary.

Thanks for putting effort in this issue, but sadly it still doesn't work on my machine. With the git clone https://github.com/codehaus-plexus/plexus-utils.git + pull I still have failing tests:

cmd (administrator):

Failed tests:
  CommandlineTest.testExecuteBinaryOnPath:103 null

Tests run: 303, Failures: 1, Errors: 0, Skipped: 0

cmd(default):

Failed tests:
  DirectoryScannerTest.testFollowSymlinks:242 null
  CommandlineTest.testExecuteBinaryOnPath:103 null
Tests in error:
  DirectoryScannerTest.testFollowSymlinksFalse:202->createTestSymlinksStructure:136->createTestSymlink:162 ╗ FileSystem

Tests run: 303, Failures: 2, Errors: 1, Skipped: 0

gitbash:

Failed tests:
  DirectoryScannerTest.testFollowSymlinks:242 null
Tests in error:
  DirectoryScannerTest.testFollowSymlinksFalse:202->createTestSymlinksStructure:136->createTestSymlink:162 ▒ FileSystem

Tests run: 303, Failures: 1, Errors: 1, Skipped: 0

Grrr ... I will try to reproduce these errors (I'm admin of my machine ... I hope there is no tricky behavior with windows symlinks & permissions) ; but not available before this weekend :-(.

Is the surefire XML gives some detail about FileSystem error ? (seems to be a problem with symlinks directory).

Is the surefire XML gives some detail about FileSystem error ? (seems to be a problem with symlinks directory).

Don't lose your time. I can reproduce the problem on Windows 10 (good news ^^). "User admin" privileges are not the same than Windows 7 (by default).

But the root cause is a The client doesn't have enough privilege (translated from French, seems A required privilege is not held by the client in English) on java.nio.file.Files.createSymbolicLink.
Not sure having a solution at this time.

CommandlineTest.testExecuteBinaryOnPath:103 null

@rfscholte : About this error, I can reproduce when I have a wrapper script (.bat, .sh) on the original Maven binary. Are you in this case or not ?

Thanks

I'm using the official Maven distribution (3.3.9/3.5.0) to build this project, no extra wrapper scripts.

It looks like this can only be solved if the JVM was started in admin-mode, no way to solve it when in default mode (which makes sense). Probably better to throw an Exception (IO or Security?) is such cases and to duplicate the related unittests with assumptions.

The problem is not only on the JVM for UT execution :-(.

A git clone in a Git Bash without admin permission does not retrieve the src/test/resources/symlinks/src/sym* paths => original test datas can't be analysed and should be hardcoded in TestCase to be sustainable.

But at this point, we would introduce a test flag on the UT execution process (please run in admin mode, under W10) ; to prevent (initially) a test flag about core.symlinks Git option ... this is very restrictive for people under W10.

It is not laziness, I know this is not the more beautiful solution as we spoke before ; but no move/creation in target/ (=> like current master) and having a test flag checking that files exists (admin mode used during clone) and are symlinks (git option used during clone) is the most simple solution (with an explicit explanation: please doing the clone in admin and using core.symlinks option).

With that, W10 developer should do the clone correctly only once (admin mode & git option), and could then work (code, execute, ...) classically, without restrictions on permissions about execution.

@rfscholte : WDYT ?

I'm such a W10 user. IIUC that would mean I will never be able to test sym-links in UTs in default mode. So those tests can be skipped with explanation. We should have enough reviewers with different operating systems who can verify the behavior.

I will never be able to test sym-links in UTs in default mode.

If git clone was done in admin mode, test sym-links in UTs in default mode works perfectly (from src/test/resources).

=> OK, I will update the PR with a skip and WARN log in case of files are not present or symlinks.

PR updated.

Symlinks

Test skipped with explanation if symlinks are not present and correct in src/test/resources/symlinks/src. System.[out|err].println used like other places in the test.

CommandlineTest.testExecuteBinaryOnPath

Output of mvn -version displayed in the Assert. Except when mvn is not in the PATH or some wrapper used (could change the wanted output), I can't reproduce the problem.

If merged, 2 TODO should be removed in DirectoryScannerTest for #27 (lines 411 & 428).

Rewrote this patch and merged it. Thanks!