com-lihaoyi / mill

Mill is a fast JVM build tool that supports Java and Scala. 2-4x faster than Gradle and 4-10x faster than Maven for common workflows, Mill aims to make your project’s build process performant, maintainable, and flexible
https://mill-build.org/
MIT License
2.2k stars 350 forks source link

Where should we put files on disk necessary for test and run commands? #3362

Closed lihaoyi closed 1 week ago

lihaoyi commented 3 months ago

Existing Solutions:

Follow up of https://github.com/com-lihaoyi/mill/pull/3347

lefou commented 2 months ago

Just quoting myself here, to have the idea recorded:

https://github.com/com-lihaoyi/mill/pull/3347#issuecomment-2275147303

I could imaging a dedicated testSandboxResources targets, which automatically get copied into the sandbox when preparing the test run. This can be helpful if the app under test needs some files.

In contrast, to the other resources, which always specify resources meant to be found on the classpath, this new target explicitly is about files in the FS at runtime, but not on the classpath.

https://github.com/com-lihaoyi/mill/pull/3347#issuecomment-2282708085

The reason why I proposed a new testSandboxResouces is the fact that test resources are already bundles up in the main jar and therefore using them directly from the filesystem blurs their correct purpose. This leads to projects having lots of test reosurces in the resouces directory, which will effectively also end up in the jar, but were never supposed to end up there. I think the fact that so many projects use the test resources folder is just convenience. Maven, who invented the src/test/resources folder is simply too hard to customized to use a better location for such resources, to begin with.

In contrast, we could easily make a distinction here, make it easy to do the right thing, and avoid encouraging users to do the not-so-correct thing. resources is supposed to be packaged up in the jar, so the correct usage of these files is via the classpath. (In Maven slang, we're speaking of something like a src/run/resources.) A new type of resources (testSandboxResources or some other name) will never end up in the package. Looks like a better place for resources a test case shall look up at run time from the filesystem. Even if we don't copy them into the sandbox but make the path accessible via a Java sysprop, it looks to me as the cleaner approach.