Resources file not visible in classes directory

[lwronski]

Hello, I have an issue with bloop run, that resource files are not copied to the classes directory.

Using this source:

$ cat src/main/resources
1 2 3 4
$ cat src/main/scala/Main.scala
import scala.io.Source

object Main extends App {
  val inputs = Source.fromResource("input").getLines.toSeq
  println(inputs.mkString(""))
}

With SBT:

$ sbt run
...
$ ls target/scala-2.13/classes/
Main$.class                     Main.class
Main$delayedInit$body.class     input

classes directory contains input file

With bloop:

After running sbt bloopInstall

$ bloop compile hello-world
...
$ ls .bloop/hello-world/bloop-internal-classes/classes-Metals-V0ZUSdL_Q7KLGmw0GcCopw\=\=-NfPLLT32T_C-HitNIi5aLQ\=\=/
META-INF                        Main$delayedInit$body.class
Main$.class                     Main.class

but with bloop classes directory doesn't contain input file

[tgodzik]

Thanks for reporting! We might not be correctly copying the results to the client class directories.

[Arthurm1]

As far as I understand - Bloop intentionally doesn't copy resources into the classes dir. Instead it puts the resources dir on the classpath (and expects it to be on the classpath of dependent projects). I guess this is an optimisation to save on file copying. This works fine for compile/test/run but not packaging. It might be easier to change the package code to include the resources dir.

[tgodzik]

Thanks for pointing that out! Bloop wasn't doing any packaging yet, so that would explain it.

[kpodsiad]

@tgodzik It's worth noting that the issue is not about packaging, @lwronski provided an example with sbt run which compiles and runs code.

For me, the main issue is that once compiled stuff shouldn't change its behavior. If bloop puts current resources from the working directory on the classpath then after compilation I may do some changes in resources. Suddenly the program is working differently and it could be very hard to spot why.

Every build tool which I know is copying resources and I expect that Bloop behaves similarly.

[crt-31]

Bump. This is still an issue.

I agree Bloop should copy the files into the classpath directory.
Also, the classloaders only support jarfiles and directories on the classpath, so if I put a.txt as a resource, bloop currently adds it to the classpath which is incorrect.
Ideally, in the bloopConfig file's "resources" field, it would take a mapping from src path to dest relpath.

[tgodzik]

Actually, coming back to it I don't really see that it's that large an issue. One of the arguments raised before:

For me, the main issue is that once compiled stuff shouldn't change its behavior. If bloop puts current resources from the working directory on the classpath then after compilation I may do some changes in resources. Suddenly the program is working differently and it could be very hard to spot why.

If you change resource and do sbt run it will pick up the new changed resources. This might only be an issue if you run from target directory, which seems like a niche case.

@crt-31 what kinds of issues are you seeing? bloop run should work correctly, the same with Metals and Scala CLI will properly package resources.

I am not too keen to change the behaviour since packaging is outside of Bloop competencies and most tools using Bloop work correctly or can easily work around this. Also, this would be a larger change for not that much benefit.

[tgodzik]

To fix the problem with files being included I raised #2553

[crt-31]

@tgodzik, Thanks for lookaing at this.
My issue is that I want to bloop support single files as resources that can be mapped into the 'jar'. While bloop doesn't package an actual jar, it does simulate packaged jars during run and test. Using classpath only partially simulates the jar as it can't handle individual files. My argument is I think bloop should support individual resource files into the 'jar', since that would make it more correct and comprehensive. (I don't really care how its supported, but copying the resource into the classes folders would probably be one way to solve it).
For instance, Sbt supports individual resource file mappings into the jar using the "mapping" configuration. There are good use cases to use this.
In my particular case, I am using Bazel, which can only specify files (not directories), so being able to specify individual file mapping would be the only proper way to specify the resources.

[tgodzik]

Fixed in #2553