New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support custom file system for @TempDir
#2400
Comments
Team decision: Since the |
Me:
You:
Not sure how they relate. 😃 Should we (Pioneer) consider working on this to create a PR or would you prefer if we didn't? |
Well, even if you put in the work to submit a PR we'd have to review it. Moreover, we would discuss how the API and implementation should roughly look like before that. So, for now, we'd prefer that you didn't. I hope you understand. 🙂 |
Of course, no worries. Just wanted to make sure. |
This issue has been automatically marked as stale because it has not had recent activity. Given the limited bandwidth of the team, it will be automatically closed if no further activity occurs. Thank you for your contribution. |
I think this issue is valuable. |
Now that |
Although the custom file system could/will be specified per declaration, it'd still be useful to have a way to set it globally, for example with a configuration property (rationale at #2889 (comment)). |
@marcphilipp @sbrannen is this up for grabs? I would like to work on it if that's fine with you. |
This adds a factory SPI to `@TempDir`, allowing to define how the temporary directory is created. This can be used for custom file systems, but it may also used for customizing how and where the directory is created for the default file system. The intended usage is to extend `TempDirFactory` and provide the class to the new `factory` attribute of `@TempDir`. Resolves #2088. Resolves #2400.
Jupiter's
@TempDir
does not allow the configuration of custom file systems. It would be nice if it would.A key motivation for me to open this issue is that custom file systems are the only thing that Pioneer's
@TempDir
can do that Jupiter's can't. Since Jupiter's is quite a bit more powerful than ours now, we'd like to remove our extension (this also prevents confusion for users), but we don't feel comfortable doing that as long as there's a feature we offer that you don't.If Jupiter isn't fundamentally opposed to such a feature, we could implement it and open a PR.
The text was updated successfully, but these errors were encountered: