While @Parameterized test works and injects parameters from a @ValueSource, getting JUnit 5 to inject a @TempDir doesn't seem to work. I get an 
org.junit.jupiter.api.extension.ParameterResolutionException: No ParameterResolver registered for parameter [java.io.File arg0] in executable [void bundle.test.JUnit5TempDirTest.tempDirTest(java.io.File)].
FWIW, I will push an integration test for this (and for @ParameterizedTest) to Gerrit soon.

(In reply to Eclipse Genie from comment #1)
> New Gerrit change created: https://git.eclipse.org/r/154300
Failing integration test showcasing the problem.
(Sorry, accidentally added this to Bug 545586; please ignore the mail from Bugzilla for that one.)

Some analysis (don't know enough about Surefire Booter setup to fix this myself, though):
- For @ParameterizedTest's @ValueSource, which works, @ValueSource and @ValueArgumentsProvider are in the same bundle (org.junit.jupiter.params).
- For @TempDir, which does *not* work, @TempDir and @TempDirectory are in different bundles (org.junit.jupiter.api and org.junit.jupiter.engine, respectively).

(In reply to Andreas Sewe from comment #3)
> - For @TempDir, which does *not* work, @TempDir and @TempDirectory are in
> different bundles (org.junit.jupiter.api and org.junit.jupiter.engine,
> respectively).
The situation seems to be more complex. Just amended the Gerrit change with a JUnit5Test using @RepeatedTest (from org.junit.jupiter.api bundle), which is implemented by @RepeatedTestExtension (from org.junit.jupiter.engine). That works, so the difference between @RepeatedTest, which works, and @TempDir, which does not must be more subtle.

I'm confused by the bug description. What are you saying?
* @TempDir does generally not work in Tycho (I have @TempDir tests running successfully with Tycho at work)
* @TempDir does not work in @ParameterizedTests in Tycho (haven't tested that myself)

(In reply to Michael Keppler from comment #5)
> I'm confused by the bug description. What are you saying?
> * @TempDir does generally not work in Tycho (I have @TempDir tests running
> successfully with Tycho at work)
For me, they do *not* work, resulting in the following error message (see <https://ci.eclipse.org/tycho/job/tycho-gerrit/2047/testReport/org.eclipse.tycho.test.surefire/JUnit5TempDirTest/testJUnit5Runner/):
org.junit.jupiter.api.extension.ParameterResolutionException: No ParameterResolver registered for parameter [java.io.File arg0] in executable [void bundle.test.JUnit5TempDirTest.tempDirTest(java.io.File)].
If you could compare your @TempDir tests with mine and perhaps comment in the Gerrit change <https://git.eclipse.org/r/#/c/154300/> where they differ, that would be awesome. Maybe I am missing some <configuration> option or so.
> * @TempDir does not work in @ParameterizedTests in Tycho (haven't tested
> that myself)
No, that is not what I am saying. I merely added some ITs for @ParameterizedTest and (more interestingly) @RepeatedTest as part of the Gerrit change; the latter (which succeed) are particularly interesting as they are AFAICT structurally similar to the @TempDir tests: the annotation is in a different bundle than the provider.

Andreas, we found that @TempDir is not initialized in Tycho also in our case. However, for us the tests did not fail, because the @TempDir was used in such a way that null was still valid (e.g. new File(tempDir, "foobar") works with a null tempDir argument).
Sorry for claiming wrongly that it works for us.

(In reply to Michael Keppler from comment #7)
> Andreas, we found that @TempDir is not initialized in Tycho also in our
> case. However, for us the tests did not fail, because the @TempDir was used
> in such a way that null was still valid (e.g. new File(tempDir, "foobar")
> works with a null tempDir argument).
That's interesting. Do you have @TempDir on a field rather than a parameter? Because that's the only way I can see how it would silently fail. For parameters, I get a org.junit.jupiter.api.extension.ParameterResolutionException, as JUnit doesn't silently inject null. But for fields I can imagine this being the case.